[00:24] <jimbaker> SpamapS, subparsers can be useful, but they usually need some programmatic help on the parse. one extreme example is what i did with jitsu watch
[00:24] <jimbaker> still better than trying to write that parser from scratch however
[00:25] <SpamapS> perhaps
[00:25] <SpamapS> I think I've wrangled it almost
[00:25] <SpamapS> but still can't suppress --help in subparsers
[00:29] <jimbaker> SpamapS, add_help=False doesn't help?
[00:29] <jimbaker> so to speak ;)
[01:23] <surgemcgee> Any still around? Is the only way to get the charm revision number with a --> cat hooks/revision <-- ?
[11:44] <_mup_> Bug #1016003 was filed: "juju debug-hooks -h" doesn't say what it does <juju:New> < https://launchpad.net/bugs/1016003 >
[12:15] <_mup_> txzookeeper/trunk r48 committed by<EMAIL_ADDRESS>[12:15] <_mup_> correct unit tests minors [thanks to ben bangert for spotting]
[12:22] <jml> I'm working on a charm that deploys code from a bzr branch. Currently, I'm fetching the branch into $PWD, which is /var/lib/juju/units/$UNIT_NAME/charm/. Is this sensible?
[12:22] <jml> Is there a better practice?
[12:26] <hazmat> jml, its sensible, but you can pull it anywhere
[12:26] <jml> what user is 'install' run as?
[12:26] <hazmat> jml all hooks run as root
[12:26] <jml> huh
[12:43] <hazmat> jcastro, ping
[13:01] <jml> is everything in the charm directory copied up to the instance indiscriminately?
[13:06] <jcastro> hazmat: pong
[13:11] <james_w> jml, yes
[13:11] <james_w> jml, or at least you can add arbitrary stuff, I don't know that e.g. metadata.yaml is copied exactly
[13:14] <marrusl> hey folks..  does juju on openstack require swift?
[13:15] <james_w> marrusl, IIUC yes, but you can point it to S3 and it works fine
[13:16] <james_w> as in, it needs object store, but it can use openstack for compute and s3 for object store
[13:16] <marrusl> james_w, aha, ok.  great, that makes sense.
[13:16] <james_w> but I don't know how auth works there
[13:17] <marrusl> I imagine it doesn't store much, but I wonder if that will be a security issue for some.  they might feel safer keeping it all inside.
[13:27] <hazmat> marrusl, there's also a standalone s3 compatible impl nova
[13:28] <hazmat> if their not using swift they can just stand that up by itself on a nova api server
[13:28] <marrusl> hazmat, oooh?  i.e. nova-objectstore?
[13:28] <hazmat> marrusl, its just a dumb s3 impl in nova for compatibility &testing, no replication etc, just stores files in a dir.
[13:29] <hazmat> but functional for juju's needs
[13:30] <marrusl> hazmat, indeed.  we will check it out.  thanks!
[14:20] <SpamapS> jml: re your question about whether its good practice to store in the charm dir or not.. I think its actually the best practice, because the charm dir gets completely deleted when the service is destroyed.
[14:22] <jml> SpamapS: I can't make the connection
[14:22] <jml> SpamapS: If you're installing a package, you don't care that it's in the system directories
[14:23] <jml> SpamapS: so why is auto-deletion from the charm dir a win if you're installing/running from a branch?
[14:23] <SpamapS> jml: I mean, if you are, at runtime, storing flag files or downloaded data or something, the charm dir is a good place to do that.
[14:23] <jml> SpamapS: ah rigght.
[14:24] <jml> SpamapS: in this context, I'm am bzr branching at install time
[14:24] <SpamapS> hm
[14:24] <SpamapS> for that I might put it somewhere else in case I re-deploy onto the box
[14:24] <SpamapS> since its basically an immutable cash
[14:24] <SpamapS> cache
[14:24] <jml> well, it's just apt by another means, no?
[14:25] <SpamapS> right, and apt is going to cache your debs in /var/cache :)
[14:42] <hazmat> SpamapS, i had to do an increment on txzookeeper latest is 0.9.6.. it looks like the build doesn't like that though
[15:06] <SpamapS> hazmat: looks like you still are using the debian dir from trunk instead of distro
[15:07] <SpamapS> hazmat: so you will need to dch -i in trunk, since the recipe uses debupstream
[15:21] <hazmat> SpamapS, ack, will check it out post meeting
[15:26] <mars> Question for the room: I saw a note about augtool in the wordpress charm.  Has anyone tried it out?
[15:27] <mars> http://augeas.net/tour.html
[15:57] <jimbaker> mars, re augtool, that's an old note on my part as a todo. but sure, it would be cool to try
[16:01] <mars> jimbaker, it has potential, a standard interface for config files is a nice idea.
[16:02] <mars> jimbaker, otherwise every charm writer will use their own way of hacking config files
[16:02] <SpamapS> mars: My feeling, after using augtool/augeas a few times, is that it is useful when you absolutely must only *edit* a complicated config file.
[16:02] <SpamapS> mars: its far simpler to use templating and just build the whole file.
[16:03] <jml> is there an idiom for 'juju-log if I can but otherwise skip'?
[16:03] <mars> SpamapS, makes sense
[16:03] <jml> (my subtly hidden question is, why isn't that an option or even the default behaviour of juju-log?)
[16:03] <SpamapS> jml: || : ?
[16:03] <imbrandon> mornin
[16:03] <mars> jimbaker, SpamapS, thanks
[16:03] <jml> SpamapS: ok.
[16:03] <SpamapS> jml: when are you failing to log?
[16:04] <jml> SpamapS: when I'm running scripts manually on the instance to debug stuff
[16:04] <jml> No JUJU_AGENT_SOCKET/-s option found
[16:06] <SpamapS> jml: I find it better to use debug-hooks for that
[16:06] <mars> jml, fwiw, we saw that exact error on the first day of our sprint
[16:06] <SpamapS> jml: as then you're running it in the appropriate context
[16:07] <jml> SpamapS: sorry, I figured debug-hooks wasn't ready for folk to use
[16:08] <SpamapS> no way, its a pretty awesome toy :)
[16:08] <mars> jml, we resolved it by making sure we used the correct procedure to run debug-hooks
[16:08] <jml> as debug-hooks --help doesn't actually say what it is, and the documentation on the website says it can't be used for install
[16:08] <SpamapS> It has proven hard to describe how to use debug-hooks.. I think we need screenshots in the documentation
[16:08] <SpamapS> jml: OH thats a bug in the docs.. that was fixed
[16:10] <mars> +1 for debug-hooks docs with screenshots.  The text description of the procedure we have written down is difficult to follow without a live byobu terminal in front of you.
[16:11] <jml> mars: OK, I'll bite. What's the correct procedure? How did you make sure you used it?
[16:11] <mars> jml, just a sec, I'll pastebin it
[16:12] <SpamapS> I do think we need to add a --debug flag to deploy which deploys and immediately fires up debug-hooks so you don't miss the install hook, as that is possible if the machine is already running.
[16:12] <mars> jml, http://pastebin.ubuntu.com/1052882/
[16:13] <jml> mars: ta
[16:14] <japage> hi
[16:15] <jml> so I have these neat bash hack that pops up an inotify thingy when long running commands finished
[16:16] <jml> I wish, I wish, I wish I could have a command that ran for as long as the deploy process took.
[16:17] <jml> fwiw, notes I've made on today's work so far: http://paste.ubuntu.com/1052894/
[16:18] <SpamapS> jml: jitsu watch
[16:19] <jml> SpamapS: oh that's right. I forgot to play with that.
[16:19] <SpamapS> jml: and when I release juju-jitsu 0.13 later today or tomorrow, it will actually have a --help :)
[16:19] <SpamapS> http://paste.ubuntu.com/1052901/
[16:20] <SpamapS> jml: still needs a lot of work.. some of the commands don't have their own --help .. but its a nice step forward. :)
[16:20] <jimbaker> jml, jitsu watch could definitely be nice for starting your notification
[16:20] <jml> SpamapS: will 'jitsu watch mysql' also stop watching if the service has an error in its deployment?
[16:20] <SpamapS> jimbaker: btw we need to be able to wildcard unit ids
[16:21] <jml> SpamapS: looks good :)
[16:21] <jimbaker> SpamapS, i think this really is covered by --num-units
[16:21] <SpamapS> jimbaker: how so?
[16:21] <jml> I really need to figure out how I can make my bash hack more readily usable by others.
[16:21] <SpamapS> jimbaker: I want to deploy, then immediately wait for a state of started. But id is not guaranteed to be 0, because the service name may have been used before.
[16:21] <jimbaker> SpamapS, let me dig out the example
[16:22] <japage> SpamapS: do you know how juju is retrieving the node's public ip when using maas? I seem to be getting <nodeName>.localdomain . In MAAS, i am using a blank domain, because I didnt feel like setting up a real domain. <nodeName> resolves in my environment, <nodeName>.localdomain does not. I think this is causing my relations to not work.
[16:22]  * jml is on libdep-service/29
[16:23] <jimbaker> SpamapS, you can do stuff like this, once the watch-ports branch is approved & merged:
[16:23] <jimbaker> timeout 600s ./sub-commands/watch \
[16:23] <jimbaker>   mysql --state=started -r "mysql wordpress" --setting=database \
[16:23] <jimbaker>   wordpress --state=started --open-port=80
[16:24] <jimbaker> so that's saying, wait until at least one unit of mysql (--num-units=1 is implied with the branch) is in the started state, and it has a database setting
[16:24] <jimbaker> likewise also wait until at least one unit of wordpress is in the started state and it has an open port of 80/tcp
[16:25] <jimbaker> SpamapS, i think that works better than wildcards on service units, really care about services here
[16:25] <SpamapS> japage: IIRC, its just 'hostname -f' .. but I could be wrong
[16:26] <SpamapS> jimbaker: ah ok thats good, I didn't realize I could use --state without a unit id
[16:26] <jimbaker> SpamapS, yeah, it's pretty nice in that way
[16:27] <jimbaker> SpamapS, you do need to specify --num-units until watch-ports branch lands however
[16:27] <japage> Spamaps: yep, that seems to be it... hmmm, i wish that didnt happen. Thanks for pointing me in the right direction
[16:27] <jml> what am I doing wrong? http://paste.ubuntu.com/1052914/
[16:28] <jml> docs say "$ jitsu watch mysql                                  # service is deployed"
[16:28] <jimbaker> SpamapS, here's another nice example, drawn from your unit test spec
[16:28] <jimbaker> timeout 600s jitsu watch \
[16:28] <jimbaker>     mysql --state=started -r "mediawiki:db mysql:db" --setting=database \
[16:28] <jimbaker>     memcached --state=started -r "mediawiki memcached" --setting=host \
[16:28] <jimbaker>     mediawiki --state=started --open-port=80
[16:28] <jml> but status says service is not deployed.
[16:29] <jimbaker> so it waits until the full stack is deployed and in a steady state, because the appropriate settings have been made and in particular mediawiki has reached the end of its -relation-changed hook and has opened a port; note in this case it ignores exposed or not
[16:29] <_mup_> Bug #1016138 was filed: The juju manpage should mention the JUJU_REPOSITORY environment variable <juju:New> < https://launchpad.net/bugs/1016138 >
[16:30] <SpamapS> japage: I think there's an assumption in MaaS that you will have working DNS
[16:32] <japage> SpamapS: It provides you with the option of using blank for the dns, which is supposed to use the maas server's dhcp to provide the dns, however i could be wrong about that.
[16:37] <imbrandon> well your problem is there is no proper domain setup, not that there isnt dns, localdomain is in the hostfile
[16:37] <imbrandon> not dns
[16:38] <imbrandon> thus the node will report it but others will not reach it. break down and setup a domain if you need one :)
[16:38] <japage> imbrandon: yea
[16:39] <imbrandon> japage: in otherwords its working as intended , you just need to setup a domain if your going to use one
[16:40] <jml> still having a bit of trouble with 'jitsu watch'
[16:40] <jml> is 'jitsu watch <service>' supposed to wait until <service> is deployed? i.e. until at least until after 'install' completes successfully?
[16:41] <japage> juju is working as intended, im just not sure why hostname -f is returning maas-1.localdomain
[16:41] <m_3> jimbaker: watch-ports is in trunk... I'll wait a day or so before another release unless anybody needs this now
[16:41] <SpamapS> jml: no, you need --state=started and --num-units=1
[16:42] <imbrandon> japage: because localdomain is set properly in the hostfile and there is no other domain setup for the box
[16:42] <jml> SpamapS: thanks.
[16:42] <SpamapS> Anybody familiar with argparse want to help me fix 'jitsu sub-command --help' ? I want to override it to pass --help to the subcommand instead of intercepting and printing lame sub-command help
[16:42] <imbrandon> japage: i was saying dns is working as intended
[16:43] <SpamapS> (only an issue in trunk.. 0.12 has no help for jitsu)
[16:43] <jimbaker> jml, when m_3 releases the next version of jitsu, you won't need to specify --num-units if using service unit specifications
[16:43] <jimbaker> unless you want to do --num-units=2 or whatever
[16:43] <jimbaker> m_3, thanks for that merge
[16:43] <imbrandon> SpamapS: what about juju its self, doesnt it do that ?
[16:43] <jml> jimbaker: 'if using service unit specifications'?
[16:43] <jimbaker> jml, correct
[16:43] <jml> jimbaker: sorry, what I meant was I don't understand that clause
[16:43] <jimbaker> i quickly realized it was an oversight
[16:44] <jimbaker> jml, not certain what you mean by which *clause*
[16:44] <SpamapS> imbrandon: juju's sub-commands are all just python modules
[16:44] <jml> jimbaker: what's a service unit specification?
[16:44] <SpamapS> imbrandon: so they all just add their sub-parser to the main parser
[16:44] <imbrandon> ahh
[16:44] <SpamapS> imbrandon: but I need to essentially say "don't print --help for sub-commands"
[16:44] <imbrandon> optparse :) heh
[16:45] <SpamapS> which I'm pretty convinced argparse just won't allow
[16:45] <SpamapS> perhaps
[16:45] <jimbaker> SpamapS, i can take a look at --help support
[16:46] <jimbaker> SpamapS, i assume you just want what we see with juju --help, right, a synopsis for each available subcommand based on the description
[16:46] <m_3> SpamapS: looks like there's a `parser = argparse.ArgumentParser(prog='PROG', add_help=False)`
[16:46] <jimbaker> from the subparser
[16:46] <imbrandon> japage: you see what i'm gettin at ? it returns that ( rightfully ) because that is in its hostfile as it should be, that does not garentee its reaschable
[16:46] <m_3> then maybe explicitly add it to the subcommands
[16:47] <SpamapS> m_3: so unfortunately, all the sub-parsers will share --help with the main command.
[16:47] <SpamapS> m_3: as in, if you don't add_help .. you get no help.
[16:47] <japage> why would, for a maas with no domain set (blank, not local, which tells it to use mDNS), cloud-init write an /etc/hosts file with <IP_ADDRESS> <hostname>.localdomain <hostname> ; instead of <IP_ADDRESS> <hostname> <hostname>.localdomain ?
[16:47] <SpamapS> and once you add it to one command
[16:48] <SpamapS> you can't add it to any other
[16:48] <m_3> it's like we need a help delegator
[16:48] <japage> nvmd, i just figured it out, /me stupid question previously...
[16:48] <SpamapS> m_3: yeah I think we just need to override the --help action with a function that is smarter than me :)
[16:48] <imbrandon> japage: becase thats how dns is designed, you need to setup a proper domain if you want to use one
[16:48] <SpamapS> m_3: but one tricky part is, I want it to use the usual --help action if there's no sub-command specified
[16:49] <m_3> right... doesn't juju do this?
[16:50] <jimbaker> m_3, indeed, that's what it does. looking at jitsu, it's roughly doing something similar
[16:50] <jimbaker> but clearly not quite there
[16:51] <jcastro> SpamapS: imbrandon: Which one of you "owns" the sexy column-on-the-side layout for the docs?
[16:51] <imbrandon> me
[16:51] <jcastro> hey can we get it reviewed and landed by say Monday PST?
[16:51] <jcastro> it's too sexy not to show off at Velocity
[16:51] <imbrandon> its supose to be landed now, but its not building
[16:51] <imbrandon> need to get in touch with IS
[16:51] <jcastro> oh, heh
[16:52] <SpamapS> probably on a lucid box or something :-P
[16:52] <imbrandon> as in the cron is broken or something
[16:52] <SpamapS> imbrandon: try in a lucid chroot, probably some missing sphinx feature
[16:52] <imbrandon> k
[16:52] <imbrandon> yea its using sphinx 0.6.3 OLD we;re all on 1.1.3
[16:52] <imbrandon> heh
[16:53] <imbrandon> jcastro: but yea as soon as we figure that out, its landed
[16:53]  * imbrandon goes to build a chroot
[17:00] <SpamapS> imbrandon: mk-sbuild ftw :)
[17:00] <imbrandon> heh
[17:00] <SpamapS> Last Generated on Jun 20, 2012. Created using Sphinx 0.6.4.
[17:00] <imbrandon> sudo debootstrap --variant=buildd --arch i386 lucid /mnt/lucid/
[17:00] <imbrandon> :)
[17:01] <SpamapS> imbrandon: schroot is your friend
[17:01] <SpamapS> one-off chroots are just a waste of time
[17:01] <imbrandon> likely but i'll keep this one until they upgrade the docs
[17:01] <imbrandon> box
[17:02] <SpamapS> Probably won't happen until 12.04.1 is released in August
[17:02] <imbrandon> yea, so we may run into this again
[17:02] <imbrandon> hopefully not, but you know
[17:02] <imbrandon> heh
[17:03] <imbrandon> brb more mt dew while that builds
[17:04] <japage> imbrandon: i set up a real domain, called localdomain. (cheating ftw) :-)
[17:05] <imbrandon> lol
[17:05] <SpamapS> imbrandon: where does that branch live btw?
[17:06] <SpamapS> since I have lucid as of 'schroot -c lucid-amd64 -u root' ;)
[17:06] <imbrandon> SpamapS: what one ? docs ? lp:juju/docs
[17:06] <SpamapS> imbrandon: oh so docs just isn't building at all right now?
[17:06] <imbrandon> right
[17:06] <imbrandon> look its still old from before all our changes
[17:06] <SpamapS> Exception occurred:
[17:06] <SpamapS>   File "/usr/lib/pymodules/python2.6/sphinx/builders/html.py", line 653, in <lambda>
[17:07] <SpamapS>     ctx['toctree'] = lambda **kw: self._get_local_toctree(pagename, **kw)
[17:07] <SpamapS> TypeError: _get_local_toctree() got an unexpected keyword argument 'maxdepth'
[17:07] <imbrandon> nice
[17:07] <imbrandon> ok one sec
[17:07] <SpamapS> heh, we really should make juju.ubuntu.com a charm
[17:07] <imbrandon> :)
[17:07] <SpamapS> like.. seriously
[17:07] <imbrandon> how its on lucid :)
[17:08] <imbrandon> unless we chroot it on the box, but yea that woudl be awesome , dogfood it
[17:08] <SpamapS> mouth.where().put(money)
[17:08] <imbrandon> ok let me fix the maxdepth issue
[17:08] <SpamapS> imbrandon: it shouldn't be on lucid forever though. :)
[17:09] <imbrandon> one sec
[17:09] <SpamapS> ./source/_templates/ubuntu1204/layout.html:{{ toctree(maxdepth=2) }}
[17:09] <SpamapS> so thats f'ing it up?
[17:09] <imbrandon> yea
[17:09] <m_3> imbrandon: redirect :)
[17:09] <imbrandon> SpamapS: just make toctree(maxdepth=2) == toctree
[17:09] <imbrandon> 2 is the default anyhow
[17:12] <japage> hmmm, appears my kludgy dns was a red herring, still seem to be having mysql issues creating relations
[17:17] <imbrandon> m_3: hehe :)
[17:17] <m_3> imbrandon: seriously... I do agree we should be dogfooding that one
[17:18] <m_3> just have the dang thing redirect to ec2
[17:18] <m_3> SpamapS: fido
[17:18] <imbrandon> yea i think i;m gonna do that today
[17:18] <imbrandon> we dont have a sphinx charm anyhow
[17:18] <imbrandon> that i know of
[17:21] <SpamapS> You know, the more I think about our need to cryptographically verify upstream software.. the more I think we should just require embedding anything not in the Ubuntu archive.
[17:21] <SpamapS> Or, an archive that is sufficiently highly available like that one.
[17:21] <SpamapS> would simplify a lot of charms to just toss tarballs into them
[17:21] <SpamapS> and make them more robust
[17:21] <imbrandon> ... the more i hear stuff like that the more i think about jcastro saying "you can do anything in a charm"
[17:22] <imbrandon> heh
[17:22] <SpamapS> YOU can do anything in a charm
[17:22] <SpamapS> But I'm not going to inflict all the crazy brandon stuff on everyone. ;)
[17:22] <imbrandon> heh well i can do anything in a deb too for that matter :)
[17:22] <SpamapS> right!
[17:22] <imbrandon> lol
[17:22] <jcastro> SpamapS: right, so like right now the mod_spdy one is worthless because the google archive times out all the time
[17:22] <jcastro> and so on
[17:22] <SpamapS> deb can do anything charms can do better.. debs can do anything charms can do...
[17:23]  * SpamapS sings a little song
[17:23] <SpamapS> there's an offline apt thing that would work for that too
[17:23] <imbrandon> SpamapS: http://s3.assets-online.com.s3.amazonaws.com/files/nginx/nginx-1.3.1.spdy.tar.gz
[17:24] <imbrandon> :)
[17:24] <SpamapS> more and more I think charms might benefit from a build step too.. where you could just run a "rebuild" that downloads and unpacks and stuff.. so the install hook isn't doing so much work
[17:24] <imbrandon> patched and ready, just not had the time to build it into a charm yet
[17:24] <SpamapS> imbrandon: yeah thats plenty available
[17:24] <SpamapS> even from outside Amazon :)
[17:25] <imbrandon> right, none pre-patched tho, thats why i made that tarbal
[17:25] <m_3> SpamapS: yeah, install feels like a beast sometimes
[17:25] <m_3> I try to move as much out of it as possible
[17:25] <m_3> can do the "build" step in config-changed really
[17:25] <m_3> win 17
[17:26] <jimbaker> SpamapS, re jitsu --help on trunk, it's just not introspecting things properly. i can fix that
[17:26] <SpamapS> m_3: did you not see my objections to kees's sbuild merge in the bug?
[17:26] <SpamapS> m_3: actually I didn't make them in the bug, whoops
[17:26] <SpamapS> m_3: anyway, we can't be dropping config options
[17:26] <SpamapS> m_3: will likely break deployed services
[17:26] <m_3> SpamapS: whoops... sorry, no didn't see that
[17:26] <SpamapS> m_3: It wasn't well communicated
[17:27] <imbrandon> well we can, we just need a way to get at the old ones
[17:27] <imbrandon> keeping the old ones promostes crift
[17:27] <imbrandon> cruft
[17:27] <SpamapS> m_3: lets just leave this one be, but the policy doc I put out described this as a 'de-facto' rule.. where if something has been around for 30+ days, it can't be dropped
[17:27] <m_3> SpamapS: roger
[17:27] <SpamapS> imbrandon: cruft can be removed in the next series
[17:27] <imbrandon> ugh that sounds bad
[17:28] <SpamapS> Until juju gives us config-set .. cruft must remain
[17:28] <imbrandon> next series 5+ years
[17:28] <SpamapS> imbrandon: no, 2 years
[17:28] <SpamapS> tho we can fix it in quantal
[17:28] <SpamapS> just that nobody will care ;)
[17:28] <imbrandon> server where most of these target
[17:28] <imbrandon> 5
[17:28] <SpamapS> imbrandon: *2*
[17:28] <SpamapS> every 2 years theres a new LTS
[17:29] <imbrandon> so you expect that everyone will upgrade ? we still have stuff in IS on lucid
[17:29] <SpamapS> I don't mind keeping the cruft around for the full LTS lifetime as long as we don't keep it forever in the current LTS
[17:29] <SpamapS> imbrandon: this isn't about everyone upgrading, its about easing development burden
[17:29] <SpamapS> existing users won't care about the cruft
[17:30] <SpamapS> I would like to see juju grow a 'deprecated' tag for options
[17:30] <SpamapS> so deploy will yell loudly
[17:30] <SpamapS> and set will warn
[17:30] <imbrandon> yea thus i say we need a way to get at historical config options not promote cruft
[17:30] <imbrandon> we are making policy based on bugs
[17:30] <SpamapS> yes we are
[17:30] <SpamapS> thats life
[17:30] <SpamapS> if we made policy on perfection, we'd have no policy :)
[17:31] <imbrandon> welll thats like me adding to the metadata.yaml cuz i could
[17:31] <SpamapS> the bug being.. ?
[17:31] <imbrandon> only approved items should be there
[17:31] <SpamapS> Thats not a bug, thats a fact. :)
[17:32] <SpamapS> One agreed upon by a pretty short discussion.
[17:32] <imbrandon> but nothign enforces that , i am just saying instead of a short lived policy lets fix the bug
[17:32] <SpamapS> its on the TODO
[17:32] <imbrandon> ok then no need for policy
[17:33] <SpamapS> Yes there's a need for a policy so we can ease unwanted affect of the bug being fixed
[17:33] <imbrandon> and how is it on the todo i just sugested it ?
[17:33] <SpamapS> Basically the policy is saying "Don't do that, because its not going to work at some point"
[17:34] <imbrandon> no it will work at some point when the bug is fixed, it dont work NOW and coudl breaak things
[17:34] <SpamapS> There's already a bug somewhere to start warning on unknown fields.
[17:34] <imbrandon> see the diff
[17:34] <imbrandon> no no
[17:34] <imbrandon> i'm on the original thing, not metadata
 see that, we just talked right past eachother
[17:34] <imbrandon> i just used that for example
[17:34]  * SpamapS capitulates
[17:34] <imbrandon> hehe
[17:35] <imbrandon> yea i think we;re on the same page just
[17:35] <imbrandon> was on diff subjects
[17:35] <imbrandon> ok /me goes back to docs
[17:36] <imbrandon> btw did you change that, can you change that toctree and rebuild to make sure i'm rtight before i commit
[17:36] <SpamapS> imbrandon: push to some other branch and I can try it
[17:36] <imbrandon> k
[17:36] <SpamapS> I tried removing the maxdepth and got something else
[17:36] <imbrandon> oh
[17:36] <imbrandon> fun
[17:36] <SpamapS>   File "/usr/lib/pymodules/python2.6/docutils/nodes.py", line 92, in setup_child
[17:36] <SpamapS>     child.parent = self
[17:36] <SpamapS> AttributeError: 'NoneType' object has no attribute 'parent'
[17:37] <SpamapS> which looks way nastier
[17:37] <imbrandon> yrs
[17:37] <SpamapS> Perhaps we can request an upgrade to 12.04 :)
[17:37] <imbrandon> bah
[17:37] <imbrandon> please
[17:37] <imbrandon> heh
[17:37] <imbrandon> but will they do it before monday ? heh
[17:38] <imbrandon> jcastro: jujucharms.com/docs has the current build too btw in a pinch, but thats on hazmat's $$ sooooooo
[17:43] <hazmat> SpamapS, yeah. i suspect its on lucid given how old the sphinx their attempting to use is
[17:46] <SpamapS> definitely lucid
[17:46] <SpamapS> such is life, unless we embed sphinx in the branch ;)
[17:46] <jml> so, I've finally got my thing deploying from my charm
[17:46] <jml> which is great
[17:46] <SpamapS> but, that would be eeeevil right ;)
[17:46] <jcastro> hey so I have been thinking SpamapS
[17:46] <SpamapS> jcastro: dangerous that
[17:47] <jcastro> what does bundling the tarball in the charm accomplish
[17:47] <jml> https://code.launchpad.net/~jml/libdep-service/juju/+merge/111396 has the MP. I would *really*, *really* appreciate a review from an experienced charmer
[17:47] <jcastro> I still have to trust you.
[17:47] <jml> by which I mean you, SpamapS
[17:47] <SpamapS> jcastro: makes the deploy/add-unit more predictable
[17:47] <jcastro> I can't confirmed that you didn't check the sha either
[17:47] <jcastro> oh ok, so you mean purely for "it will work every time"
[17:48] <SpamapS> jcastro: presumably we will add some crypto verification to the charm store beyond what we have now (https for launchpad). Either way, we're trusting the charmer to provide a valid SHA.. so providing the actual file is the same thing
[17:48] <SpamapS> jml: I'll look right now, since you asked so nice
[17:48]  * jcastro nods
[17:48] <jml> SpamapS: thanks.
[17:49] <SpamapS> I *do* think we need to build a Packages.gz type of file for the charm store
[17:49] <SpamapS> which is signed
[17:49] <jml> SpamapS: I have to leave in the next couple of minutes, so please put your comments on the MP.
[17:49] <SpamapS> and have the commits to the bzr branches signed too probably
[17:49] <SpamapS> jml: will do
[17:49] <jml> SpamapS: thanks!
[17:56] <surgemcgee> The *config-changed* hook will trigger the first time the charm is deployed. Is this functional to anyone?
[17:58] <imbrandon> yes, thats where most of my install actions come in
[17:58] <imbrandon> ver little is done in the install hook for me
[18:01] <SpamapS> surgemcgee: aye, its guaranteed to run, unless install or start fails
[18:02] <jml> incidentally, the juju tests take a while to run.
[18:02] <jml> speaking from personal experience, you want to get on that sucker now, or you'll become Launchpad.
[18:06] <SpamapS> jml: 7 minutes?
[18:07] <SpamapS> jml: for 98% coverage..
[18:07] <SpamapS> jml: also remember that the python code base is done growing. :)
[18:07] <SpamapS> jml: on an SSD they only take 4 minutes.
[18:07] <jml> SpamapS: I just ran ./test on my machine w/ an SSD and it's still going
[18:07] <jml> SpamapS: maybe I'm supposed to run the tests differently
[18:07] <SpamapS> ./test
[18:07] <SpamapS> thats all I do
[18:07] <jml> SpamapS: way more than 7m
[18:08] <SpamapS> takes at most 7 minutes
[18:08] <SpamapS> jml: bad java maybe?
[18:08] <jml> SpamapS: possible
[18:08] <SpamapS> it taxes zookeeper quite a bit
[18:08] <SpamapS> jml: also try 'eatmydata ./test'
[18:08] <jml> SpamapS: I just have whatever data is on the system
[18:08] <SpamapS> that at least disables all the syncing that zookeeper wants to do
[18:08] <jml> SpamapS: so, hang on....
[18:08] <jml> if the python code base is "done growing" as you say
[18:09] <jml> then there's zero point in me contributing patches for the bugs I've filed.
[18:09] <SpamapS> jml: Its not done living, its just not going to get any more feature dev.
[18:09] <SpamapS> making it easier to use, clarifying stuff with online help, those will all help users while we transition to go
[18:10] <jml> and when that's done, we can do it all over again
[18:10] <jml> 738 seconds for the test run.
[18:10] <SpamapS> (and also the go team will be expected to not regress any of the bugs that are fixed before we declare it "complete"
[18:10] <jml> well, I wish them all the best with tht.
[18:12] <imbrandon> SpamapS: can we just get IS to turn on -backports and -updates and such
[18:12] <imbrandon> root@server-1339205906-az-1-region-a-geo-1:~/docs# cat /etc/issue.net
[18:12] <imbrandon> Ubuntu 10.04.4 LTS
[18:12] <imbrandon> root@server-1339205906-az-1-region-a-geo-1:~/docs# dpkg -l|grep sphinx
[18:12] <imbrandon> ii  python-sphinx                   1.0.1-1~lucid1             tool for producing documentation for Python
[18:12] <imbrandon> root@server-1339205906-az-1-region-a-geo-1:~/docs#
[18:13] <imbrandon> and it builds perfect with no changes
[18:13] <SpamapS> jml: review posted to the MP
[18:14] <jml> SpamapS: thanks!
[18:14] <imbrandon> how do we make that happen sooner than later ? heh
[18:14] <SpamapS> imbrandon: backports might be a good way to go
[18:14] <SpamapS> imbrandon: I'll open up an RT
[18:15] <imbrandon> ok ty, mention that its broken now hehe
[18:15] <SpamapS> imbrandon: trying with lucid-backports enabled
[18:15] <imbrandon> but yea i enabled -backports and -updates and it worked
[18:16] <imbrandon> deb http://archive.ubuntu.com/ubuntu lucid main restricted universe multiverse
[18:16] <imbrandon> deb http://archive.ubuntu.com/ubuntu lucid-updates main restricted universe multiverse
[18:16] <imbrandon> deb http://archive.ubuntu.com/ubuntu lucid-backports main restricted universe multiverse
[18:16] <imbrandon> deb http://archive.ubuntu.com/ubuntu lucid-security main restricted universe multiverse
[18:16] <SpamapS> easy pastemonkey
[18:16] <imbrandon> suprised the bot dident kick me
[18:17] <SpamapS> I don't think we have that bot
[18:17] <imbrandon> ahh ubottu normally in #ubuntu-* chans guess not #juju
[18:18] <imbrandon> anyhow yea, i bet they are much more likely to do that then update to 12.04 by monday
[18:19] <imbrandon> and it requires no docs work arounds that way
[18:20] <imbrandon> still agree with the charm tho
[18:20] <imbrandon> man i wish there was 3 of me
[18:27] <imbrandon> jcastro: awe, not using my button :(
[18:28] <jcastro> I have to use the official blurry button
[18:28] <imbrandon> heh k
[18:28] <jcastro> burned by the design team
[18:28] <imbrandon> wonder how i can make mine "official"
[18:30] <imbrandon> joey used it once or twice now on posts ( made a wordpress shortcode for him ) and they seemed to love it :)
[18:31] <imbrandon> infact i should release that plugin for the wp shortcode
[18:38] <SpamapS> imbrandon: ok, IS ticket submitted
[18:38] <SpamapS> jcastro: whats significant about Monday ?
[18:38] <imbrandon> SpamapS: rockin ty
[18:38] <jcastro> SpamapS: velocity, not like during a talk or anything
[18:39] <jcastro> but it would be nice to know when we mention stuff that it'll be pretty
[18:39] <SpamapS> jcastro: Indeed
[18:39] <imbrandon> now if i could just edit the wiki
[18:39] <imbrandon> lol
[18:40] <jcastro> lol, let's not get crazy
[18:40] <SpamapS> The IS guys said it should be no big deal to pull in the backport, but they might prefer to just upgrade to precise.
[18:40] <imbrandon> rt is on it, they emailed me back
[18:40] <jcastro> rock and rolll
[18:40] <imbrandon> jcastro: yes was more toung in cheek
[18:40] <jcastro> SpamapS: yeah, I would think they'd prefer to just go all 12.04.
[18:40] <imbrandon> either way works for me
[18:40] <jcastro> SpamapS: backports, a sure way to know you're the only guy running that configuration on your production box. :)
[18:40] <imbrandon> :)
[18:41] <SpamapS> hazmat: bug 984484 .. galapagos? really? Its not even In Progress.. and I'm releasing *tomorrow*
[18:41] <_mup_> Bug #984484: subordinate charms should be able to open ports <juju:Confirmed for bcsaller> < https://launchpad.net/bugs/984484 >
[18:41] <jcastro> SpamapS: also, where do I find the juju codename/release/date mapping?
[18:41] <SpamapS> jcastro: https://launchpad.net/juju
[18:41]  * imbrandon starts preping to do new rpm and osx builds tomarrow
[18:41] <SpamapS> we're 2 weeks late on galapgos
[18:42] <jcastro> ah, got it
[18:42] <m_3> SpamapS: can you do notes on the juju release process pls :)
[18:42] <SpamapS> expected: 2012-06-06
[18:42] <m_3> SpamapS: assume it's similar to jitsu?
[18:42] <SpamapS> m_3: Yeah I think that probably deserves something in internals
[18:42] <SpamapS> m_3: its not going to be as smooth as jitsu's ;)
[18:42] <SpamapS> since we've never done a "release"
[18:43] <m_3> oh, gotcha
[18:43] <imbrandon> i think i'm going to reload my mini tonight, i need the extra space that OSX is using
[18:43] <imbrandon> heh
[18:43] <jcastro> what? no, you have to test the OSX releases!
[18:43] <m_3> imbrandon: especially if you're able to do the osx in a vm thing
[18:43] <imbrandon> jcastro: osx in a VM
[18:44] <imbrandon> :)
[18:44] <hazmat> SpamapS, is galapagos closed?
[18:45] <imbrandon> lunchtime bbiab
[18:47] <m_3> SpamapS: we have real (lp) milestones though... I'm curious to see how this differs
[18:49]  * m_3 is interested in learning lp for real after the branch-distro fiasco :)
[18:52] <hazmat> on two weeks late
[18:54] <m_3> hazmat: he mentioned releasing it tomorrow... don't really know what closed means here tho
[19:02] <imbrando1> mmm i need enough money to buy an island, or at least 98% of one ...
[19:03] <imbrandon> that has a solid internet connection too :(
[19:09] <SpamapS> hazmat: Closed, not sure. I did say I wanted to release tomorrow. :)
[19:10] <SpamapS> m_3: branch-distro is about the weirdest part of launchpad I've seen.
[19:10] <SpamapS> m_3: nothing else does things like it does.
[19:20] <jcastro> SpamapS: sadness is watching you pilot not here.
[19:20] <jcastro> j/k
[19:23] <SpamapS> jcastro: I'm on deck next week. :)
[19:24] <SpamapS> 7 items in the queue.. we're pretty healthy anyway :)
[19:44] <imbrandon> mmm this cant be good, whole bowl of instant pudding to myself :)
[19:51] <SpamapS> imbrandon: http://www.mtv.com/videos/misc/173418/240-dollars-worth-of-pudding.jhtml
[19:53] <SpamapS> awww yeah
[19:55] <imbrandon> SpamapS: zomg
[19:55] <imbrandon> that is classic
[20:01] <imbrandon> "... now kids, the rumor says that the `M` in `MTV` used to stand for `Music`, *children all giggling* ..."
[20:21] <robbiew> jcastro: m_3: SpamapS: any one available for a charm school at the Texas Linux Fest Aug 3-4...in San Antonio?
[20:21] <robbiew> I'm not sure we need one, but just asking
[20:21] <jcastro> I can go if you want
[20:22] <robbiew> I just wonder how many folks there would be interested
[20:23] <robbiew> last year had good following
[20:23] <robbiew> and I suspect we given rackspace is diamond...maybe more cloud folks this year
[20:23] <robbiew> gonna be f*cking hot
[20:23] <robbiew> lol
[20:23] <jcastro> heh
[20:23] <imbrandon> heh
[20:24] <imbrandon> thats one thing i dont miss about TX, 70's on my b-day , in mid december :)
[20:24] <robbiew> I actually don't mind 70s in december...it's the freezing rain and snow the week after that always messes with me
[20:25] <robbiew> and of course the hell on earth heat...peaking in August
[20:25] <imbrandon> hahahah yea, i lived in galviston so the gulf squelched that a lil
[20:26] <m_3> robbiew: lemme look
[20:27] <imbrandon> i do miss the beach parties tho, mmm nothing like watching the sun rise on east beach :)
[20:28] <SpamapS> robbiew: could possibly make it
[20:28] <SpamapS> Need to find my wife a nanny before serious travel commences, but we might have one by then.
[20:28] <robbiew> imbrandon: ugh...galveston, literally the armpit of the USA
[20:29] <robbiew> in every sense of the word....hot..humid...wet
[20:29] <imbrandon> hahahah , this was pre-katrina
[20:29] <robbiew> ..and occasionally stinky
[20:29] <imbrandon> :)
[20:29] <SpamapS> robbiew: don't forget the hairy part
[20:29] <imbrandon> LOL
[20:30] <robbiew> SpamapS: meh...I wouldn't spend a travel voucher with the wife for this one
[20:33] <m_3> robbiew: yeah, I can go
[20:34] <robbiew> m_3: cool, well I'll let you know by next week if we end up doing one
[20:42] <m_3> robbiew: ok, thanks
[20:42] <robbiew> no...thank YOU ;)
[20:43]  * m_3 will think of it as an extended sauna
[20:44] <imbrandon> heh
[20:45] <imbrandon> SpamapS / m_3 : you see the new MB with retna displays and paper thin ? WOW
[20:47] <m_3> imbrandon: yup... I'm still waiting for the little 11" air to fit into the family budget
[20:47] <imbrandon> yea, thats the next one i am getting , the 11inch
[20:47] <m_3> it was a tradeoff... house or computer?
[20:48] <imbrandon> heh, good call
[21:19] <tooth> not as upgradeable though. :-(
[21:19] <tooth> soldered on ram.
[21:21] <tooth> and a proprietary flash disk thing.
[21:21] <imbrandon> i rarely if ever upgrade machines, i buy new ones. so no biggie
[22:11] <SpamapS> imbrandon: Yes I've seen them. No I don't really understand why I need to buy one. ;)
[22:11] <SpamapS> I am looking for a new machine..
[22:11] <SpamapS> but I want to see if I can actually buy a non apple machine
[22:12] <imbrandon> good luck :)
[22:12] <imbrandon> heh j/k
[22:12] <m_3> imbrandon: please ignore comments on bug #1000088
[22:12] <_mup_> Bug #1000088: charm needed: newrelic sysmond <Juju Charms Collection:Fix Committed by imbrandon> < https://launchpad.net/bugs/1000088 >
[22:12] <imbrandon> this openbuildservice is  .... intresting
[22:12] <imbrandon> m_3: okies :)
[22:13] <imbrandon> m_3: hahahah should i ask ?
[22:15] <bkerensa> jcastro: Up for membership today -> https://wiki.ubuntu.com/lynxman
[22:17] <SpamapS> what about negronjl?
[22:18] <SpamapS> since the DMB decided to pass the buck
[22:20] <bkerensa> =/
[22:20] <lynxman> SpamapS: I applied for the membership meeting 3 weeks ago, if you could give me a testimonial I'd be very grateful
[22:20] <lynxman> SpamapS:  https://wiki.ubuntu.com/lynxman
[22:25] <SpamapS> lynxman: done
[22:26] <lynxman> SpamapS: thanks
[22:26] <lynxman> SpamapS: !! :)
[22:26] <bkerensa> lynxman: is this go two for you?
[22:26] <lynxman> bkerensa: yes, first one was for UCD and got declined
[22:26] <bkerensa> ahh
[22:29] <jcastro> same thing happened to juan
[22:29] <jcastro> we need to get him to apply for normal membership
[22:29] <jcastro> m_3: did you apply for membership yet?
[22:36] <SpamapS> Yeah seriously, its time
[22:37] <SpamapS> jcastro: I do like the idea, more and more, of us having a charm store council and being able to grant membership.
[22:37] <jcastro> I specifically didn't ask for that council to be able to grant membership
[22:37] <jcastro> because I didn't think it was necessarry
[22:38] <SpamapS> Its weird to have people who don't really understand how juju helps Ubuntu saying no to people like Juan though
[22:38] <imbrandon> for those that contribute charms but not much else i can totaly see it, same thinking for the kubuntu council granting memberships etc
[22:38] <imbrandon> yea
[22:40] <jcastro> SpamapS: I think that's what we should fix though
[22:40] <jcastro> not working around it by making another member-granting council
[22:40] <jcastro> (IMO)
[22:40] <bkerensa> jcastro: lynxman in #ubuntu-meeting for Ubuntu Membership :)
[22:41]  * imbrandon goes to lurk
[22:41] <bkerensa> he is up now ;)
[22:41]  * SpamapS can't watch
[22:41] <bkerensa> quiet debate is occuring
[22:42] <lynxman> bkerensa: quite silent
[22:42] <bkerensa> ikr
[22:42] <bkerensa> maybe they found a nice video on youtube
[22:43] <jcastro> imbrandon: heh, what the heck is mims doing to your newrelic charm bug
[22:43] <imbrandon> lol no idea :)
[22:44] <imbrandon> using it for a guiney pig i think
[22:45] <lynxman> wohooo!
[22:45] <imbrandon> grats
[22:47] <negronjl> SpamapS: what do I need to do to apply for membership
[22:47] <lynxman> imbrandon: thanks :)
[22:48] <SpamapS> negronjl: -> ask lynxman he just got it ;)
[22:49] <negronjl> lynxman: you still around ?
[22:49] <lynxman> negronjl: I am!
[22:49] <negronjl> lynxman: what did you do to apply for memebership ?
[22:49] <imbrandon> negronjl: put up a nice wiki page saying what all you do in/for ubuntu , ask for peeps to vouch for you, then attend a cc meeting :)
[22:50] <lynxman> negronjl: let me tell you in #siteam
[22:50] <jcastro> negronjl: mira, we can reuse your application
[22:50] <jcastro> it'll be the exact same
[22:51] <negronjl> jcastro:  that's what I was thinking of using
[22:51] <jcastro> it'll be the exact same
[22:51] <negronjl> jcastro: I also have a wiki page ( wiki.ubuntu.com/JuanNegron )
[22:51] <jcastro> looks like you applied to the wrong board.
[22:51] <jcastro> yeah
[22:51] <negronjl> jcastro:  sure .. we'll go with that :/
[22:52] <jcastro> negronjl: 27 june is the next one, we'll be at velocity
[22:53] <jcastro> we can just prep it together while we are there
[22:53] <negronjl> jcastro: k
[22:53] <negronjl> jcastro: thx
[22:53] <jcastro> don't worry man, we're on it.
[22:53] <jcastro> like white on rice
[22:53] <imbrandon> heh
[22:54] <lynxman> negronjl: I'll root for you :)
[22:55] <jcastro> imbrandon: this newrelic charm is exciting
[22:55] <imbrandon> me 3 :) would have for lynxman as well had i known prior :)
[22:55] <jcastro> I think a bunch of people can find use for it
[22:55] <negronjl> lynxman: thx man ... it looks like I'll need it :)
[22:56] <imbrandon> jcastro: there are 2 now, that one and the php one, and i was just thinking aobout doing the ruby one too since the app i've been working on is rails
[22:56] <imbrandon> :)
[22:56] <jcastro> hey
[22:56] <imbrandon> but yea they rock
[22:56] <jcastro> do they have any node.js graphing stuff?
[22:56] <lynxman> imbrandon: aww thanks :)
[22:56] <imbrandon> yea , i can whiop up the node one in a few mintues
[22:57] <imbrandon> they are all basicly the same , just a few minor changes
[22:57] <imbrandon> to each one for the runtime
[22:57]  * imbrandon goes to grab the ruby and node ones
[22:59]  * SpamapS would like to see just one good graphing solution.. tho ganglia and munin are at least "traditionally" good
[22:59] <imbrandon> jcastro: for node stuff tho you want some sexy meteor tho
[22:59] <jcastro> we do
[22:59] <imbrandon> meteor is frackin bad ass
[23:00] <imbrandon> http://meteor.com/screencast
[23:00] <imbrandon> watch that, like 3 minutes
[23:00] <jcastro> yay, another platform!
[23:00] <imbrandon> it will change your life as a webdev
[23:00] <imbrandon> nah
[23:00] <jcastro> I need pretty graphs yo
[23:00] <imbrandon> its node
[23:00] <imbrandon> not new
[23:01] <imbrandon> but a new way to code, but its all nodejs , will run on any node server anywhere
[23:01] <imbrandon> no special sauce
[23:01] <jcastro> oh it certainly looks cool
[23:01] <jcastro> I just need an app, not a framework to write an app
[23:02] <imbrandon> they have a few examples, like wordplay would be sweet
[23:02] <jcastro> yeah
[23:02] <imbrandon> to show off realtime node client<->server
[23:02] <negronjl> jcastro: ping
[23:06] <imbrandon> jcastro: kinda nice too since it will be a sub to anything
[23:06] <jcastro> yuuup
[23:09] <imbrandon> HA! good thing i loged into newrelic, looks like OMG has been minus one webhead a day or so
[23:09] <imbrandon> but since the setup is so sweet no notice :)
[23:10] <imbrandon> SpamapS / jcastro: check this out too http://uptime.omgubuntu.co.uk/585467
[23:11] <imbrandon> one minute imcrments
[23:11] <jcastro> heh
[23:11] <jcastro> nice!
[23:11] <SpamapS> imbrandon: what is that?
[23:11] <SpamapS> ah pingdom
[23:11] <imbrandon> pingdom
[23:11] <imbrandon> but like i can tell for certain there has been no downtime in the last 7 days , not even for a minute
[23:11] <imbrandon> :)
[23:12] <SpamapS> imbrandon: indeed
[23:12] <jcastro> that's pretty sexy
[23:12] <imbrandon> :)
[23:13] <imbrandon> there is an API, wonder if i could rangle that into a reporting charm
[23:13] <imbrandon> get the endpoint from the relation and then setup the reporting for that endpoint
[23:13] <imbrandon> hrm
[23:20] <imbrandon> jcastro: erm i guess there isnt any node newrelic, only ruby php python and .net
[23:20] <imbrandon> and sysmon
[23:21] <imbrandon> there is also a generic restapi so i wonder if there is a 3rd party one
[23:21]  * imbrandon looks
[23:30] <imbrandon> HAHA rock, Joyent ( one of the big companies behind nodejs ) sugests use the php agent for monitorying and gives an example on how to use it from node
[23:30] <imbrandon> :)
[23:33] <imbrandon> damit i wish gimp was as good as photoshop
[23:37] <SpamapS> wow.. how messed up is my head that I think I want this https://github.com/alevchuk/vim-clutch
[23:39] <imbrandon> hahha
[23:39] <imbrandon> nice
[23:40] <imbrandon> do it!


[07:56] <juliank> queues are empty :D
[07:57] <juliank> I see failures "Could not connect to ftpmaster.internal:80 (<IP_ADDRESS>), connection timed out" again, will investigate :/
[08:01] <cjwatson> juliank: see ~is-outage on mattermost
[08:01] <cjwatson> you will get that when ftpmaster is actually down ...
[08:03] <juliank> cjwatson: oh, well, I can't see that from ~is-outage :D
[08:05] <laney> heh, yeah, not going to get very far if ftpmaster.itself is not available
[08:09] <laney> juliank: did you see that the error rate dropped off, what's up with that?
[08:09] <laney> if you go to 7 days and select arm64 normal/abnormal only
[08:10] <juliank> laney: it's an absolute number and we finished the queue
[08:11] <laney> I mean it dropped off at like the start of Saturday
[08:11] <laney> like something about the later tests didn't cause so many errors
[08:11] <laney> maybe when we finished the SRUs?
[08:12] <juliank> or less load on the cloud from builders?
[08:13] <laney> hmm
[08:15] <juliank> typing sever instead of server when typing server delete kind of makes sense
[08:50] <laney> juliank: wdyt about the shim bug dann pointed out on devel@, does that seem feasible to you?
[08:52] <juliank> laney: I replied to him
[08:52] <juliank> laney: maybe in the wrong email
[08:53] <juliank> laney: the shim bug is waiting for review
[08:54] <juliank> I cannot comment on whether they are related
[08:54] <juliank> doesn't _seem_ like it
[08:55] <juliank> the shim one is null pointer dereferencing at exit boot services; we crash _after_ that
[08:55] <juliank> also we crash in older releases without the broken shim :D
[08:55] <juliank> so I could comment after all
[09:00] <laney> ah yeah, just saw it after I asked you :D
[11:32] <laney> sil2100: heya, to deploy your private branch to staging...
[11:32] <laney> do we need to get swift users created?
[11:33] <laney> shouldn't the X-Auth-Token config be a dict user -> token?
[11:33] <laney> sorry, maybe I forgot some details
[12:20] <sil2100> laney: let me get back to you in a few minutes!
[12:23] <laney> sil2100: ack, going for lunch now anyway
[12:25] <sil2100> laney: ok, so regarding this: so from the POV of the workers and the ADT infra, the only thing that's should be needed credential-wise is the X-Auth-Token, since that's enough to get access to the results (user not needed here)
[12:26] <sil2100> laney: a separate user might be needed indeed as this is passed for instance via the 'swiftuser' request parameter, to decide which user to add read access to the results
[12:27] <sil2100> laney: that being said, I think we could temporarily just use X-Auth-Token of the staging main swift user
[12:28] <sil2100> laney: it can be a separate user for security, in case the token somehow leaks out or something and such a separate-user token will in theory have much less powers over the whole database
[12:28] <utkarsh2102> sil2100: hello, I am another hints MP whenever you have time?
[12:29] <utkarsh2102> no rush, though.
[12:29] <utkarsh2102> (cf: https://code.launchpad.net/~utkarsh/britney/+git/britney/+merge/404113)
[12:29] <utkarsh2102> ugh, s/I am/I have/g :)
[12:32] <sil2100> utkarsh2102: hey! Reviewed o/
[12:34] <utkarsh2102> sil2100: awesome, thank you! though I added "all" intentionally because it's gonna be a problem for all architectures, at least until ruby3.0 transition, which is waiting on the Debian archive.
[12:35] <utkarsh2102> I suspect, someone will need to add the hints again for the next versions for s390x. So I just wanted to save the time others might spend because it's going to be unrelated.
[12:35] <utkarsh2102> anyhow, would you still want me to change to specific version instead? I'd be happy to! :)
[12:38] <utkarsh2102> s/all architectures/all versions on s390x/g
[12:43] <sil2100> I'd prefer us bumping it knowingly than risking us forgetting about it and just missing out real failures on this architecture
[12:48] <utkarsh2102> sil2100: gotcha, +1 then, fixed the MP! \o/
[12:48] <sil2100> Merging!
[12:48] <utkarsh2102> thanks a bunch! :D
[13:46] <laney> sil2100: I was trying to make it fit in with what you do in the worker, when uploading a private result - you grant access to the named swiftuser there
[13:46] <laney> so we should be using the X-Auth-Token for that user on the reading side I guess
[13:47] <laney> we don't need to make one for staging, fair enough, but it does probably need the ability to take multiple users
[13:50] <laney> shouldn't be too hard to modify that, I can do it if you want
[13:51] <laney> I guess just container -> token should be fine
[14:13] <sil2100> laney: hm, that can be a good idea I suppose!
[14:14] <sil2100> laney: I mean, right now the X-Auth-Token can be simply the one from the main swift users that the workers use to upload results, as it should have read access to all the containers
[14:14] <sil2100> (as the owner)
[14:15] <sil2100> The swiftuser parameter is more so that the X-Auth-Token from the britney side of ESM or any other users (so outside of the ADT infra) can access it with their own X-Auth-Token
[14:17]  * laney nods
[14:21] -queuebot:#ubuntu-release- Unapproved: lvm2 (groovy-backports/main) [2.03.07-1ubuntu3 => 2.03.11-2ubuntu4~ubuntu20.10.1] (core, i386-whitelist)
[14:25] <laney> sil2100: crap, I just read that X-Auth-Tokens are valid for 24 hours typically
[14:27] <sil2100> Wait, but you can't set the date?
[14:27] <laney> I didn't find something that says you can
[14:27] <laney> did you?
[14:27] <sil2100> Since when I created test ones they were only valid for an hour, but it felt like something that's configurable (forgot to check)
[14:28] <laney> I just read https://docs.openstack.org/zaqar/queens/user/authentication_tokens.html and it says "Applications should be designed to re-authenticate after receiving a 401 (Unauthorized) response from a service endpoint"
[14:28] -queuebot:#ubuntu-release- Unapproved: sanlock (groovy-backports/universe) [3.6.0-4build1 => 3.8.2-2~ubuntu20.10.1] (i386-whitelist)
[14:29] <sil2100> Oooookaay
[14:30] <laney> hmmmmm
[14:30] <sil2100> "Authentication tokens expire after a time period that the authentication service defines. When a token expires, use of the token causes requests to fail with a 401 Unauthorized response. To continue, you must obtain a new token."
[14:30] <sil2100> eh
[14:31] <sil2100> This was such a good idea, too bad I didn't actually dive into the expliration time last week
[14:33] <laney> I didn't notice either /o\
[14:33] <laney> thinking about if there's a way round this
[14:51] -queuebot:#ubuntu-release- Packageset: Removed libclc from i386-whitelist in impish
[14:51] -queuebot:#ubuntu-release- Packageset: Removed nvidia-graphics-drivers-340 from i386-whitelist in impish
[14:51] -queuebot:#ubuntu-release- Packageset: Removed nvidia-graphics-drivers-418-server from i386-whitelist in impish
[14:51] -queuebot:#ubuntu-release- Packageset: Removed nvidia-graphics-drivers-435 from i386-whitelist in impish
[14:51] -queuebot:#ubuntu-release- Packageset: Removed nvidia-graphics-drivers-tesla-460 from i386-whitelist in impish
[14:51] -queuebot:#ubuntu-release- Packageset: Added libreoffice to i386-whitelist in impish
[14:51] <sil2100> I think we just need to switch to the full-credentials approach
[14:54] <laney> not very thrilled by that
[14:55] <laney> we could probably try to get a read-only user, and grant to 'swiftuser' and that one
[14:58] <laney> or the swiftuser can go away in that case maybe
[14:58]  * laney is asking IS for input
[15:06] -queuebot:#ubuntu-release- Unapproved: apt (hirsute-proposed/main) [2.2.3 => 2.2.4ubuntu0.1] (core, i386-whitelist)
[15:20] -queuebot:#ubuntu-release- Unapproved: python3.8 (focal-proposed/main) [3.8.5-1~20.04.3 => 3.8.10-0ubuntu1~20.04] (i386-whitelist) (sync)
[15:28] <sil2100> As said, the swiftuser part was just to make sure that the ESM britney instance doesn't have to host like the main ADT SWIFT credentials, since that has all write and read access to everywhere
[15:29] <sil2100> This way the ESM britney has a swiftuser user that has read rights to the given container and is all fine. On the ADT side we can use the main creds as those are there anyway
[15:29] <sil2100> (for the workers)
[15:34] <laney> yeah for uploading that's what'll happen
[15:35] -queuebot:#ubuntu-release- Unapproved: gcc-10 (focal-proposed/main) [10.2.0-5ubuntu1~20.04 => 10.3.0-1ubuntu1~20.04] (i386-whitelist) (sync)
[15:36] -queuebot:#ubuntu-release- Unapproved: gcc-10-cross (focal-proposed/main) [6ubuntu3 => 6ubuntu4] (i386-whitelist) (sync)
[15:38] -queuebot:#ubuntu-release- Unapproved: gcc-10-cross-ports (focal-proposed/universe) [5ubuntu2 => 5ubuntu3] (i386-whitelist) (sync)
[15:40] <laney> sil2100: have you got a sketch of the proposed-migration side?
[15:40] <laney> I'm worried that it'll need access to keystone
[15:47] -queuebot:#ubuntu-release- Unapproved: gcc-10-cross-mipsen (focal-proposed/universe) [2+c1ubuntu1.1 => 2+c1ubuntu1.2] (no packageset) (sync)
[15:51] <sil2100> laney: you mean sketch of using the whole SWIFT credentials instead of X-Auth-Token?
[15:53] <laney> sil2100: yeahhhhhhhhhhhhhh
[15:53] <laney> like I don't know how you can pass those from a random external server
[15:53] <laney> I wonder if you tried it already and it worked
[15:54] <laney> I think maybe you *have* to use the X-Auth-Token there ...
[15:54] <laney> hopefully I'm not right 😬
[15:54] <sil2100> hm, well, so I was using swiftclient and was only testing it against canonistack locally, via VPN
[15:54] <sil2100> And it worked fine with my local config, so I assumed we could do the same if we're on the same network?
[15:55] <laney> I think they fw will block access to keystone
[15:55] <laney> the*
[15:55] <laney> let me check from snakefruit
[15:55] <sil2100> Can't we modify the fw rules in that case? Man, I really liked the idea of X-Auth-Token, I don't feel like getting back to full creds :<
[15:55] <laney> huh ok it works from there, whyyyYYYYY
[15:58] <sil2100> laney: as for the branch, I can revert the X-Auth-Token changes and push that to a separate branch for review/test if anything
[15:58] <laney> ack
[15:58] <laney> you can do a 'git revert' and push it on top if you want
[15:59] <laney> we can rebase them both away later on
[16:49] <rbalint> sil2100, i'm trying to queue https://bileto.ubuntu.com/#/ticket/4583 , but it seems there is a token error https://bileto.ubuntu.com/static/britney/ust_log_2021-06-14_16:30:01.txt
[16:49] <rbalint> sil2100, could you please check it?
[17:50] <sil2100> Oh no, hmm
[17:52] <sil2100> rbalint: oh, so you want to trigger ust for that silo, yes?
[19:24] -queuebot:#ubuntu-release- Unapproved: accepted gcc-10 [sync] (focal-proposed) [10.3.0-1ubuntu1~20.04]
[19:29] -queuebot:#ubuntu-release- Unapproved: accepted gcc-10-cross [sync] (focal-proposed) [6ubuntu4]
[19:32] -queuebot:#ubuntu-release- Unapproved: accepted gcc-10-cross-ports [sync] (focal-proposed) [5ubuntu3]
[19:33] -queuebot:#ubuntu-release- Unapproved: accepted gcc-10-cross-mipsen [sync] (focal-proposed) [2+c1ubuntu1.2]
[23:19] -queuebot:#ubuntu-release- New binary: acorn [amd64] (impish-proposed/universe) [8.0.5+ds+~cs19.19.27-2] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: libfplus [arm64] (impish-proposed/none) [0.2.13-1] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: libfplus [ppc64el] (impish-proposed/none) [0.2.13-1] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: node-token-types [amd64] (impish-proposed/none) [2.1.1+~cs0.2.0-2] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: ntcard [arm64] (impish-proposed/none) [1.2.2+dfsg-2] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: ntcard [s390x] (impish-proposed/none) [1.2.2+dfsg-2] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: libfplus [amd64] (impish-proposed/none) [0.2.13-1] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: libfplus [s390x] (impish-proposed/none) [0.2.13-1] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: ntcard [ppc64el] (impish-proposed/none) [1.2.2+dfsg-2] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: libfplus [armhf] (impish-proposed/none) [0.2.13-1] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: r-bioc-ballgown [amd64] (impish-proposed/none) [2.22.0+dfsg-2] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: ntcard [amd64] (impish-proposed/none) [1.2.2+dfsg-2] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: r-bioc-ioniser [amd64] (impish-proposed/none) [2.14.0+dfsg-2] (no packageset)
[23:27] -queuebot:#ubuntu-release- New binary: ogre-1.12 [s390x] (impish-proposed/universe) [1.12.10+dfsg2-1.1] (no packageset)
[23:30] -queuebot:#ubuntu-release- New binary: ogre-1.12 [amd64] (impish-proposed/universe) [1.12.10+dfsg2-1.1] (no packageset)
[23:33] -queuebot:#ubuntu-release- New binary: libfplus [riscv64] (impish-proposed/universe) [0.2.13-1] (no packageset)
[23:33] -queuebot:#ubuntu-release- New binary: ogre-1.12 [ppc64el] (impish-proposed/universe) [1.12.10+dfsg2-1.1] (no packageset)
[23:33] -queuebot:#ubuntu-release- New binary: ntcard [riscv64] (impish-proposed/universe) [1.2.2+dfsg-2] (no packageset)
[23:41] -queuebot:#ubuntu-release- New binary: ogre-1.12 [arm64] (impish-proposed/universe) [1.12.10+dfsg2-1.1] (no packageset)
[23:42] -queuebot:#ubuntu-release- New binary: ogre-1.12 [armhf] (impish-proposed/universe) [1.12.10+dfsg2-1.1] (no packageset)


[00:00] <mtaylor> thumper: if I'm going to propose some work on launchpad and I want to get direction approved, should I file a blueprint or a bug?
[00:00] <mtaylor> thumper: or should I write a patch containing a user story and submit that :)
[00:01] <thumper> mtaylor: you should have a pre-implementation call :)
[00:01] <lifeless> mtaylor: chat with a dev
[00:01] <lifeless> mtaylor: everything else is makework.
[00:01] <lifeless> mtaylor: you could chat on the lp-dev list, here, or on voice
[00:02] <mtaylor> lifeless: ok.... just wanted to be sure I was prepping for the right thing
[00:02] <lifeless> if you need a persistent record, I'd start with the list, or a bug [perhaps]
[00:02] <mtaylor> _I_ don't need a persistent record - I just wanted to make sure I was being friendly and all
[00:03] <lifeless> whats your ideal, when someone does stuff for dribble?
[00:03] <mtaylor> lifeless: depends on scope of work - if it's a new feature or something decent sized, we ask them to file a blueprint
[00:03] <lifeless> what do you use the blueprint for?
[00:04] <mtaylor> lifeless: tracking work against the task
[00:04] <mtaylor> lifeless: they'll then tie their bzr branch to that blueprint, we'll use the blueprint during planning meetings to check progress on it
[00:04] <mtaylor> etc.
[00:04] <lifeless> mtaylor: but not for deciding on direction :)
[00:05] <mtaylor> lifeless: well, not directly, no... although we'd certainly like to :)
[00:05] <mtaylor> lifeless: but fair enough
[00:33] <mwhudson> lifeless: say, do you have any particular opinions about pyunit-compatible test runners?
[00:34] <lifeless> why yes, I do
[00:34] <mwhudson> lifeless: which would you recommend? (he asks, half expecting "bzrlib's")
[00:35] <lifeless> testrepository if you can
[00:35] <lifeless> failing that testtools.run
[00:35] <mwhudson> oh, testtools has a runner?
[00:35] <mwhudson> didn't know that
[00:35] <lifeless> and failing that your own glue to bzrlib.tests.$stuff
[00:35] <lifeless> my current absolute favourite is testrepository
[00:36] <lifeless> which is generally used via subunit.run
[00:36] <lifeless> which backs onto testtools stuff
[00:36] <mwhudson> lifeless: i'm currently writing up a python programming practices document for the $censored work
[00:37] <mwhudson> so i get to inflict my opinions on how some things should be done
[00:37] <lifeless> have I shown you testrepository and all the bits
[00:37] <mwhudson> i'm aware of it
[00:37] <lifeless> I think you should experience before recommended
[00:37] <lifeless> s/ed/ing/
[00:37] <mwhudson> yeah
[00:38] <lifeless> so, apt-get install testrepository
[00:39] <lifeless> this doesn't do test discovery yet, it will trivially when someone gets around to testtools + discovery [foords thing] glue
[00:39] <lifeless> I should ask, do you have say, 10 minutes for a quick tour ?
[00:40] <mwhudson> yes
[00:40] <mwhudson> ah, i was going to ask about discovery
[00:40] <lifeless> it would be good to add that
[00:40] <lifeless> perhaps you could find a day and JFDI ?
[00:40] <mwhudson> perhaps
[00:41] <lifeless> let me see, how hard would it be
[00:41] <lifeless> http://pypi.python.org/pypi/discover/0.3.2
[00:43]  * mwhudson looks at unittest2 and finds nothing that looks particularly good, apart from the discovery stuff
[00:44] <lifeless> yeah
[00:44] <lifeless> I asked if he'd contribute to testtools
[00:44] <lifeless> but apparently it was too hard. Or something.
[00:44] <lifeless> <- a little bitter
[00:45] <mwhudson> :(
[00:45] <mwhudson> i think i told him to look at testtools at pycon 2009
[00:45] <lifeless> anyhow
[00:45] <lifeless> shiny shiny stuff
[00:45] <lifeless> so, do you have something small with a test_suite method ?
[00:45] <mwhudson> um
[00:45] <mwhudson> no
[00:46] <lifeless> if not, make something small with a test_suite method (because thats something that stock pyunit, and thus testtools.run, can support)
[00:46] <lifeless> just
[00:46] <lifeless> from testtools import TestCase
[00:46] <lifeless> class foo(TestCase):
[00:46] <lifeless>  def test_pass(self):pass
[00:47] <lifeless>  def test_fail(self):self.fail('sad')
[00:47] <bryceh> bzr question...  I have a branch with an html file in it.  I want whenever I commit to the branch that it updates a "last-updated-date" line in the footer.  Any way to set up bzr to do this easily?
[00:47] <lifeless> def test_suite():
[00:47] <jelmer> bryceh: see the bzr-keywords plugin
[00:47] <lifeless>     return unittest.TestLoader().loadTestsFromNames('foo')
[00:47] <lifeless> in foo.py
[00:47] <bryceh> jelmer, thanks
[00:48] <lifeless> mwhudson: we can test this works with 'python -m testtools.run foo.test_suite'
[00:48] <lifeless> make another file, .testr.conf
[00:48] <lifeless> [DEFAULT]
[00:49] <lifeless> test_command=python -m subunit.run $IDLIST
[00:49] <lifeless> test_id_list_default=foo.test_suite
[00:49] <lifeless> EOF
[00:49] <lifeless> then, testr init; testr run
[00:49] <lifeless> should show you one failure
[00:49] <lifeless> testr run --failing
[00:49] <lifeless> should run the one failing test
[00:49] <lifeless> tour over
[00:50] <lifeless> for more detail, keep chatting, and/or read /usr/share/doc/testrepository/MANUAL.txt
[00:50] <mwhudson> ok
[00:50] <lifeless> I totally totally depend on the 'run only failing' stuff now that I have it
[00:51]  * jelmer admits to also being a total testr fanboy
[00:51] <mwhudson> hm yeah that looks pretty neat
[00:51] <mwhudson> py.test had this --looponfailing thing that i remember using a bit, ages ago
[00:52] <lifeless> sounds similar
[00:52] <lifeless> this is not coupled to test runner or python
[00:52] <lifeless> as long as there is an interface, and it can output subunit, it works ;)
[00:53] <mwhudson> so where should discovery fit?
[00:54] <mwhudson> as an alternative to test_id_list_default ?
[00:55] <lifeless> so
[00:55] <lifeless> small bit of glue in subunit.run
[00:55] <lifeless> then you'd do
[00:55] <lifeless> python -m subunit.run --discover [discovery arg]
[00:55] <lifeless> when running it by hand
[00:55] <lifeless> for .testr.conf you'd do
[00:56] <lifeless> test_id_list_default=--discover <whatever you decided on>
[00:56] <lifeless> thats the entire set of changes needed AFAICT
[00:56] <mwhudson> ah, so subunit needs to change a bit?
[00:57] <lifeless> tiny tiny
[00:57] <lifeless> not the protocol, just the glue to setup a test list
[00:58] <lifeless> rather than calling the unittest loader with the parameters its given
[00:58] <lifeless> it needs to call the discover loader
[00:58] <lifeless> thats it
[00:59] <mwhudson> right
[00:59] <mwhudson> ok well it doesn't sound too hard...
[00:59] <lifeless> note that this workflow works with trial --reporter=subunit too
[00:59] <lifeless> for huge value of entertaining
[01:00] <mwhudson> right, and i guess trial already has its own approach to discovery
[01:00] <lifeless> yes
[01:04] <lifeless> I'd like bzr switch to stash the .testrepository with the branch
[01:04] <lifeless> or perhaps I want a push/pop thing in testr
[01:06] <mwhudson> lifeless: i guess i could find this out myself, but does trial have anything like the load_tests() protocol?
[01:06] <lifeless> it honours test_suite
[01:06] <lifeless> I would like to teach it load_tests
[01:06] <lifeless> because load_tests is much better
[01:07] <lifeless> mtaylor: ^ also another reason to use cppunit -or- make gtest talk subunit
[01:08] <mwhudson> lifeless: why is load_tests 'much' better?
[01:08] <mwhudson> i can see how it's a bit more convenient
[01:09] <lifeless> test multiplication is a lot easier with it
[01:09] <lifeless> less duplication
[01:10] <lifeless> and no hard-coding of TestSuite class
[01:10] <lifeless> and no hard coding of loader
[01:10] <lifeless> the whole process becomes more easily mutated, 2-line patches to change things, rather than change-per-source-file
[01:12] <mwhudson> ah yeah, that makes sense
[02:39] <mars> lifeless, you wouldn't happen to have any idea why the zope testrunner + subunit would produce a partial traceback like this?: http://pastebin.ubuntu.com/443072/
[02:51] <lifeless> mars: that looks truncated
[02:52] <mars> lifeless, yes.  I thought a buffer in my own code was holding the output, but it turns out to be somewhere in the testrunner itself.
[02:52] <mars> lifeless, is the subunit protocol written down anywhere?  I'm wondering if that "error: ..." line is correct?
[02:53] <mars> lines that say "failure: " end with "[ multipart "
[03:00] <mars> lifeless, found the protocol, EBNF in the README.  Clever.
[03:02] <lifeless> :)
[03:02] <lifeless> so you have the simple output there
[03:02] <lifeless> [\n
[03:02] <lifeless> there should be a trailing ]\n
[03:03] <lifeless> and the output of a simple attachment like that is done at once, so it has nearly no chance of not completin
[03:03] <lifeless> g
[03:03] <lifeless> if its blowing up in stopTest
[03:03] <lifeless> one possibility is stdout being closed or something
[03:04] <lifeless> but that would fly in the face of actually *getting* that traceback
[03:09] <mars> yeah :/
[03:09] <mars> lifeless, could it be that the parent process (that watching the subunit stream) choked on some child process output?
[03:10] <mars> silently ate it maybe?
[03:11] <mars> thread dump in the parent says nothing out of the ordinary:
[03:11] <mars> Thread 1
[03:11] <mars> #0 0x00007f535ef0cdc2 in select () from None
[03:11] <mars> #1 0x00007f535ec39784 in time_sleep (self=<value optimized out>, args=<value optimized out>) from /build/buildd/python2.5-2.5.2/Modules/timemodule.c
[03:11] <mars> /var/launchpad/tmp/eggs/zope.testing-3.9.4-py2.5.egg/zope/testing/testrunner/runner.py (521): resume_tests
[03:19] <mars> according to the code and thread dump it looks like the parent is running on the while-input loop
[03:19] <lifeless> how long does this take to trigger ?
[03:19] <lifeless> and is it reliable ?
[03:19] <lifeless> if its not too long, you might try running the child under strace
[03:19] <lifeless> as an ugly debugging hack
[03:19] <mars> not reliable, maybe 40% failure rate, takes 2 hours to trigger with a full suite run.
[03:19] <lifeless> also is it only on that test, or a general sort of thing?
[03:20] <mars> it happens anywhere in the windmill portion of the suite
[03:20] <lifeless> does it happen if you just run windmill?
[03:20] <mars> that is why I really really wanted that full traceback :)
[03:20] <mars> lifeless, not in my testing, no
[03:21] <mars> and it doesn't happen on buildbot either
[03:21] <mars> just on ec2
[03:21] <lifeless> and you can trigger it locally running everything ?
[03:21] <lifeless> or on ec2 w/windmill only ?
[03:21] <mars> nope
[03:21] <mars> only when running the full suite, including the windmill suite, on ec2
[03:23] <lifeless> bugger
[03:23] <lifeless> uhm
[03:23] <lifeless> buffer limit ?
[03:23] <mars> hmm
[03:23] <lifeless> oh
[03:23] <lifeless> you use wait() right
[03:24] <lifeless> IIRC that can trigger on anything in your process group
[03:24] <lifeless> want to bet that there is a child of a child which is being allowed to zombie until the child goes, and you're getting a signal on that child-of-child, which you then close the pipe on the immediate child and things go boom
[03:24] <lifeless> or something
[03:24] <mars> well, this is without using my code, but I can check the zope testrunner - it may .wait() as well
[03:25] <lifeless> I'm not terribly convinced of my explanation there
[03:25] <mars> lol
[03:25] <mars> my first thought was "yay IPC is fun"
[03:28] <mars> hmm
[03:28] <mars> lifeless, looking at the zope testrunner code, what you say may be possible.  I would have to think through the process though
[03:29] <mars> there is a note in there how reading the child process (the child layer) can be interrupted by EINTR if something sends SIGCHLD
[03:32] <mars> but it would be really really odd that I have seen the traceback truncated on that stopTest line so many times
[03:34] <lifeless> thats true
[03:35] <lifeless> OTOH subunit writes in a very predictable pattern
[04:14] <lifeless> how do I tell what version of bzr-loom launchpad has ?
[04:22] <lifeless> mwhudson: thumper: ^
[04:24] <mwhudson> lifeless: i guess look at utilities/sourcedeps.conf
[05:33] <thumper> probably quite old
[05:50] <ScottK> poolie: I was thinking about your comments about high dkim verification failure rates.  You might be better off doing dkim verification at the border too and then consuming an authresults header inside LP.
[06:22] <poolie> hi scottk
[06:22] <poolie> do you mean my speculation that many of them may have inadvertently broken headers?
[06:22] <poolie> two more thoughts there:
[06:23] <poolie> 1- it's much easier for me to land code into the bit of launchpad that processes incoming mail than it is to do that _and also_ get sysadmins to set up something in the border MTA
[06:23] <poolie> 2- i'd like to hope that we don't actually damage the mail on the way from our DC border in to the incoming queue
[06:23] <poolie> imbw
[06:23] <poolie> but i thought i'd try verifying them there first and if it turns out 100% are broken, i guess we'll know
[06:49] <mwhudson> given that we successfully verify gpg-signed mail, we can't damage it that badly (although i guess that doesn't sign headers?)
[09:18] <henninge> jtv-eat: the query looks acutally quite simple, given that I already have the product id and the sourcepackagename(s).
[09:18] <henninge> http://paste.ubuntu.com/443212/
[11:02] <deryck> Morning, all.
[11:29] <ScottK> mwhudson: A dkim signature covers a lot more of the message than a gpg signature.  The one case I've managed to see real success data of a large enterprise trying to do dkim verification on a second tier MTA and not on the border it had a significantly lower verification reliability than cases where I've seen it done on the border MTA.
[11:32] <mwhudson> ScottK: that makes sense
[11:32]  * mwhudson goes to bed
[12:53] <deryck> BjornT, ping
[13:01] <BjornT> hi deryck
[13:28] <wgrant>  /builders is timing out on both production and edge.
[13:28] <noodles775> Yep... saw that too :/
[13:29] <wgrant> How's it dying?
[13:29] <noodles775> view/other_builders
[13:30] <noodles775> wgrant: I'll paste the oops..
[13:30] <wgrant> Hm. That's a bit odd.
[13:31] <noodles775> wgrant: http://pastebin.ubuntu.com/443300/
[13:31] <wgrant> Ah.
[13:37] <leonardr> jamesh, i have a storm question
[13:38] <jamesh> leonardr: shoot
[13:39] <leonardr> is it possible to define a global hook equivalent to __storm_flushed__, or do i need to create a superclass/mixin and make everything inherit the behavior?
[13:40] <jamesh> leonardr: there is an internal event for that, but it is not part of the public API
[13:41] <jamesh> what would you want to use it for?
[13:44] <leonardr> jamesh: see https://code.launchpad.net/~leonardr/launchpad/test-representation-cache/+merge/26513
[13:44] <leonardr> i'm invalidating a memcached cache
[13:48] <jamesh> leonardr: ah.  The event I was thinking of is just fired once in response to store.flush() -- not once per object
[13:50] <leonardr> ah, ok
[13:50] <leonardr> it sounds like a superclass/mixin is the best bet
[13:51] <jamesh> leonardr: there are also internal "flushed" events for each object, but no way to globally register for all objects
[13:52] <jamesh> leonardr: note that not all data modifying Storm APIs will result in Python objects being flushed.
[13:53] <leonardr> jamesh: I'm talking to stub about that now. are you thinking of his "4) Using Storm for bulk updates, inserts or deletions."?
[13:54] <jamesh> leonardr: right.  The ResultSet set() and remove() methods
[13:54] <noodles775> wgrant: temporary patch - can you check pls: http://pastebin.ubuntu.com/443324/
[13:55] <jamesh> there isn't a bulk insert method in Storm, but I doubt you care too much about inserts if you're working with a cache
[13:55] <wgrant> noodles775: Looks fine.
[13:55] <wgrant> Are we blaming missing indices for the slow query?
[13:56] <noodles775> I'm assuming so, but haven't checked yet... want to get the page back up so we can fix it properly in time.
[13:56] <wgrant> Yeah.
[14:02] <stub> jamesh: store.execute(Update({Person.displayname: 'foo'}, Person.name=='stub')) would be how to get Storm to do updates without clearing the cache (not that we do that, but it would be nice to be able to do that).
[14:03] <jamesh> stub: you don't even really need to go behind Storm's back like that
[14:04] <stub> I thought that would be the blessed approach for bulk updates; didn't think that *was* going behind Storm's back ;)
[14:04] <jamesh> stub: if I use ResultSet.set() to do a bulk update, you'll only see __storm_flushed__() calls for the objects that are actually live in memory
[14:04] <stub> Ahh... that would be a better approach for bulk updates ;)
[14:05] <jamesh> it is really only intended to help you keep local caches up to date (e.g. storing computed values on the Python object) -- not external ones like I assume you're talking about
[14:06] <stub> So there is a check to see if the object is live. We could hook in there to clear the cache at that point... although there are still problems we can only solve at the database level. Not sure if they are problems we really need to worry about at this stage.
[14:06] <stub> Oh... no we couldn't since we won't know the keys :-(
[14:47] <deryck> Does sinzui have a mark-released button feature again?  A script?  Or too much time on his hands? :-)
[14:54] <sinzui> deryck, I used my script from *before* the feature that I had to retracted. I discovered we failed to update a lot of bugs on 10.04, 02
[15:00] <bac> reviewers meeting starting now
[16:17] <gmb> deryck, bug 386757 has been fixed for malone, hasn't it?
[16:17] <mup> Bug #386757: JavaScript for subscribing should be refactored for reuse <Launchpad Bazaar Integration:Fix Released by rockstar> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/386757>
[16:18] <gmb> Ah, or am I getting confused about branches that have landed but don't actually fix the bug?
[16:19] <deryck> gmb, not really fixed completely.
[16:19] <gmb> deryck, Ah, okay.
[16:20] <deryck> gmb, I did some work, rockstar did some work, and once we have state on the bug subscriptions, then we can do more work to unify our approaches.
[16:20] <deryck> though I think rockstar went really different from my work
[16:20] <gmb> deryck, Okay, I'll add it to the subs story.
[16:20] <gmb> And we can take a look at it later.
[16:20] <deryck> gmb, yeah, we should look again late in the UI refactor for this story.  It will most certainly have to touch the js subscribing code.
[16:20] <gmb> Right.
[16:21] <rockstar> deryck, I think my work was the culmination of discussions you and I had at the lazr-js sprint/UDS
[16:22] <rockstar> deryck, also, I have a branch that I've been trying to get back to that does the wizard widget, so we should have that at some point as well.
[16:23] <deryck> rockstar, right, I knew we talked about it.  I just meant it's more different than alike to what we have now in bugs.  but better, definitely.
[16:24] <rockstar> deryck, ah yes, because branch subscriptions have state, and you had planned to add the same to bugs.
[16:25] <deryck> rockstar, exactly.
[16:25] <deryck> So I think it will line up nicely with our subscriptions refactor the next couple months.
[16:29] <rockstar> deryck, sweet.
[16:34] <henninge> sinzui: I have a question about packaging if you have 2 minutes ;)
[16:35] <sinzui> I can help
[16:35] <henninge> sinzui: Is it correct that we are now copying packaging links whenever a new distroseries is created?
[16:35] <sinzui> Yes. they were copied.
[16:36] <henninge> sinzui: for maverick or for all series?
[16:36] <sinzui> for maverick using the script that bootstraps soyuz
[16:37] <sinzui> When we copy the packages from lucid to maverick and started the builds, we also copied the packaging links
[16:38] <henninge> sinzui: and that will happen on each new series?
[16:38] <henninge> in the future?
[16:39] <sinzui> yes.
[16:39] <henninge> sinzui: thanks, great help. ;)
[16:39] <sinzui> It is only for Ubuntu because only Ubuntu uses soyuz
[16:41] <henninge> sinzui: well, it looks like only Ubuntu supports packaging anyway, at least UI-wise.
[16:41] <henninge> "+ubuntupkg" ...
[16:42] <sinzui> correct
[16:45] <rockstar> henninge, yes, if you try and build for anything but Ubuntu, you can really bugger the build farm. abentley knows from experience.
[16:47] <henninge> rockstar: cool, that makes things easier for me, too.
[17:24] <abentley> noodles, why did you turn buildbase.queuebuild into a staticmethod?
[19:23] <thumper> jelmer: http://launchpadlibrarian.net/49567000/chicken-chicken-git-mirror.log
[19:29]  * maxb ponders creating a dev.launchpad.net/FailingBzrSvnImports to gather common failure cases, and wonders if some such thing exists already
[19:30] <maxb> Also, what is the current situation with svn imports requiring a username password? Does that still require losa intervention on the import slaves?
[19:30] <mars> gary_poster, ping, buildout question, when you have some spare time
[19:33] <gary_poster> mars, what's up?
[19:35] <mars> gary_poster, being annoyed by buildout picking the first zope.interface it sees, then barfing when it reads versions.cfg and realizes that it needs an older zope.interface
[19:37] <mars> gary_poster, just a sec, ran it through -vvvv, and it says there is a version conflict when loading zc.recipe.testrunner
[19:38] <mars> so it could be that zc.recipe.testrunner needs a newer zope.interface
[19:38] <gary_poster> ok
[19:38] <gary_poster> are you specifying the version of zc.recipe.testrunner?
[19:39] <mars> gary_poster, yep.  According to zc.recipe.testrunner, it does not need an explicit zope.interface
[19:40] <gary_poster> mars, sounds odd.  You have a branch for me to look at?
[19:40] <mars> gary_poster, yes, I'll push the changes
[19:41] <gary_poster> ok
[19:42] <mars> gary_poster, bzr branch lp:~mars/lazr-js/1.0
[19:42] <gary_poster> k
[19:43] <mars> gary_poster, also worth noting: the Makefile uses a LAZR_SOURCEDEPS_DIR variable, and mine points to ~/.buildout/
[19:43] <gary_poster> k
[19:45] <mars> gary_poster, zope.interface-3.5.1 is in the global download-cache, but it doesn't want to use it.  The global eggs/ directory only has zope.interface-3.5.3 (maybe because buildout refuses to build the 3.5.1 egg)
[19:49] <gary_poster> mars, the buildout.cfg file is trying to do something that appears to be against your goals.  ...wanna talk on mumble?
[19:50] <mars> gary_poster, sure
[19:50] <gary_poster> k, I'm there :-)
[21:04] <lifeless> mars: there was a import failures wiki page some time back
[21:05] <mars> maxb, ^
[21:08] <lifeless> bah
[21:08] <lifeless> sorry mars
[21:09] <mars> np :)
[21:28] <mars> lifeless, gary_poster, by the way, by hacking our testrunner I managed to get it to spit out the full windmill suite hang traceback: http://pastebin.ubuntu.com/443544/
[21:28] <lifeless> grah
[21:28] <mars> ?
[21:29] <mars> oh
[21:29] <gary_poster> "Look," Gary said intelligently, "a ValueError!"  Though it does look like something in subunit on the face of it.
[21:29] <mars> lifeless, ?
[21:29] <lifeless> checking the code
[21:30] <lifeless> so, error is not None - this is a plain pyunit api call
[21:30] <lifeless> rather than a lovely shiny testtools one
[21:31] <lifeless> stopTest was called
[21:31] <lifeless> and then the zope testrunner formatter is calling addError
[21:31] <lifeless> from within stopTest
[21:31] <lifeless> thats odd
[21:32] <lifeless> the error object is failing in _exc_info_to_string
[21:32] <lifeless> so err is not a exc_info tuple
[21:32] <lifeless> its something else
[21:32] <lifeless> look at zope/testing/testrunner/formatter.py
[21:32] <lifeless> whats the easiest way to get that for me? I have a 2 month old checkout of lp
[21:33] <lifeless> mars: ^
[21:34] <mars> lifeless, looking
[21:34] <mars> lifeless, check in eggs/zope.testing-3.9.4
[21:34] <mars> do you have that version?
[21:35] <lifeless> sec, starting the vm
[21:35] <lifeless> yes, I do
[21:35] <lifeless> well, a py2.5.egg
[21:35] <lifeless> should be good enough
[21:36] <mars> that's the one
[21:36] <lifeless> ok so this is subunut glue
[21:36] <lifeless> and its calling _get_text_details
[21:36] <lifeless> yes, its buggy
[21:37] <lifeless> I'll put a patch up
[21:38] <mars> lifeless, wow, thanks!
[21:41] <lifeless> ok, grab lp:~lifeless/zope.testing/subunit
[21:42] <lifeless> I don't know if passes tests, because it blows up when I follow the getting started instructions
[21:42] <mars> ok
[21:42] <mars> lifeless, it will take a while to run a new round of tests.  A few hours :(
[21:43] <mars> it will probably have to wait for tomorrow.
[21:43] <lifeless> https://code.edge.launchpad.net/~lifeless/zope.testing/subunit/+merge/26638
[21:43] <lifeless> mars: so anyhow, its something blowing up in another thread, but the error reporting codepath was broken
[21:44] <mars> ok
[21:44]  * mars waits for the diff to update
[21:44] <lifeless> so we'll still expect an error
[21:44] <lifeless> but it should be relevant to the windmill tests this time
[21:44] <mars> \o/
[21:45] <mars> that would be a big step forward
[21:45] <mars> Hurray for cascading failures!
[21:45] <lifeless> :)
[21:45] <lifeless> actualy, hurray for untested code :P
[21:49] <mars> lifeless, many thanks.  I'll let you know how it goes.
[21:49] <lifeless> please do
[21:49] <lifeless> sidnei: when you get back
[21:49] <lifeless> https://code.edge.launchpad.net/~lifeless/zope.testing/subunit/+merge/26638
[21:53] <mars> by coincidence, this may have been the source?  Exception in thread Thread-3 (most likely raised during interpreter shutdown):
[21:53] <mars> Traceback (most recent call last):
[21:53] <mars>   File "/usr/lib/python2.5/threading.py", line 486, in __bootstrap_inner
[21:53] <mars>   File "/usr/lib/python2.5/threading.py", line 446, in run
[21:53] <mars>   File "/var/launchpad/tmp/eggs/windmill-1.3beta3_lp_r1440-py2.5.egg/windmill/server/https.py", line 398, in start
[21:53] <mars>   File "/usr/lib/python2.5/SocketServer.py", line 218, in handle_request
[21:53] <mars> <type 'exceptions.AttributeError'>: 'NoneType' object has no attribute 'error'
[21:53] <lifeless> very likely
[21:53] <lifeless> the check was a threading thingy
[21:55] <mars> so my 'reprint the exception' code in bin/test actually spat out the entire error
[21:56] <mars> who knows why it was getting truncated
[21:57] <mars> wait, spoke too soon.  There is nothing in the on-disk capture file, just the console.  May have just been a luck break.
[22:09] <maxb> Is there a good way to hold a conversation with the requester of a vcs import?
[22:09] <lifeless> 'contact this person' in launchpad
[22:10] <maxb> ... and manually keep the whiteboard up to date with the state :-/
[22:10] <lifeless> yes :(
[22:12] <maxb> In a most perplexing move, someone's trying to register a ~lrcshow-x/lrcshow-x/trunk vcs-import when ~vcs-imports/lrcshow-x/trunk already exists
[22:12] <mwhudson> maxb: hey, at least you can see who registered the import now
[22:12] <mwhudson> that was one of the more frustrating problems with the ye olde system
[22:12] <maxb> But given the history of their svn repository, they clearly don't understand version control very well
[22:17] <lifeless> mwhudson: so what were your testing framework thoughts after looking at stuff yesterday
[22:18] <mwhudson> lifeless: i admit to getting a little sidetracked
[22:19] <mwhudson> lifeless: i think discover + subunit + testr run looks pretty nice though
[22:29] <maxb> Could someone look up OOPS-1614M3672 for me? (occurred attempting to rename a vcs-import branch)
[22:29] <lifeless> sec
[22:29] <lifeless>   Module lp.code.model.branchnamespace, line 135, in validateRegistrant
[22:30] <lifeless>     % (registrant.displayname, owner.displayname))
[22:30] <lifeless> BranchCreatorNotMemberOfOwnerTeam: Max Bowsher is not a member of lrcShow-X team
[22:30] <lifeless> zomg 500ms of sql time there
[22:30] <thumper> maxb: arse
[22:31] <thumper> maxb: was that over the api?
[22:31] <maxb> No, web ui
[22:31] <thumper> maxb: what did the form look like for the owner?
[22:31] <thumper> maxb: you should have had a dropdown
[22:32] <thumper> maxb: if you didn't, it is a bug
[22:32] <maxb> oh, I see
[22:33] <thumper> maxb: BTW I think you are doing an awesome job with the imports
[22:33] <maxb> I have edit perms by virtue of being in ~vcs-imports, but that means I can edit a branch of which I'm not in the owner team
[22:33] <maxb> So the vcs-imports special edit hack has been incompletely applied
[22:34] <thumper> maxb: you should be able to edit the branch yes
[22:34] <thumper> maxb: however you can only assign to a team you are a member of
[22:34] <thumper> maxb: the owner widget should be a drop down for you
[22:35] <maxb> I am not trying to change the branch owner. It is a dropdown. It's objecting about the fact that the existing owner of the branch is not one that I would be permitted to assign the branch to, despite the fact that I can edit the branch
[22:37] <maxb> i.e. it's over-aggressive validation. I suspect it's never been an issue before because ~vcs-imports have often been ~bazaar-experts previously
[22:37] <thumper> oh
[22:37] <thumper> arse
[22:37] <thumper> this is exactly the same problem as with the source package branches
[22:37] <thumper> maxb: can you file a bug please
[22:37] <maxb> Sure
[22:37] <thumper> thanks
[22:44] <maxb> lifeless: may I have some more of the traceback?
[22:46] <mwhudson> thumper: an oops is a better result than maxb accidentally assigning the branch to himself i guess :-)
[22:58] <sidnei> lifeless, i'm done for the day, but will look into it tomorrow
[22:58] <lifeless> sidnei: tresquis is on it
[22:58] <lifeless> sidnei: but thanks
[23:08] <maxb> 588943 ftr
[23:17] <sidnei> lifeless, even better. thanks!
[23:27] <wgrant> Hmm.
[23:27] <wgrant> It looks like if you have a 1.0 API override (because the devel API has changed, and we need to retain compat), beta (which came before 1.0) doesn't inherit it.


[20:53] <jrwren_> greg-g: happy 21st birthday to your co
[21:01] <cmaloney> <3
[21:25] <Scary_Guy> https://arstechnica.com/information-technology/2022/01/backdoor-for-windows-macos-and-linux-went-undetected-until-now/
[22:09] <jrwren_> the retropie went smoothly, but one of my BT controllers doesn't register dpad directions at all :(
[22:09] <jrwren_> I'll try some other controllers.
[22:09] <jrwren_> It was a good easy project to spend an hour with my daughter so that was nice.
[22:13] <greg-g> jrwren_ cmaloney: thanks!