[07:05] <stub> Can anyone help with an lxc environment issue? I can bootstrap fine, but 'juju ssh 0' is prompting for a password. I have no problems with openstack.
[07:41] <m_3> stub: try `juju ssh posgresql/0` instead... machine-id's a little wonky with the local provider
[07:42] <m_3> ok, maybe with a 't' in there :)
[07:44] <m_3> just `ssh<EMAIL_ADDRESS>should work ok too... just not using the machine-id
[07:46] <stub> m_3: So I can't use the unit name, because deploy is leaving the unit stuck in a 'pending' state. juju status isn't giving me an ip address either -         public-address: null
[07:46] <stub> So my guess would be the lxc container's network is borked, except that commands like 'juju status' and 'juju debug-log' are working...
[07:50] <stub> hmm.... debug-log showing me nasty encoding failures, and 2.7 python paths. Which leads me to an open bug about lxc using python3 and exploding because juju is python2 and has PYTHONPATH set.
[07:51] <stub> So I think I'm on openstack until that is resolved ;)
[07:51] <m_3> stub: yeah, iirc raring lxc is still unhappy with juju
[07:51] <stub> So lemme just set up a precise instance using lxc.... and.... umm....
[07:51] <m_3> think the python2/3 issue isn't there in other series (just was working with precise local provider this morning)
[07:52] <stub> Does lxc inside lxc actually work, or does the universe implode?
[07:52] <m_3> yikes... haven't tried that one... I do lxc in kvm
[07:53] <m_3> actually have a precise ec2 instance spun up where I was working with precise lxc just now
[07:53] <stub> You people with your fast ping times...
[07:53] <m_3> in a novotel atm :)
[07:54] <m_3> stub: please lemme know if lxc is inceptable
[07:55] <m_3> that's probably a big ole rabbit hole though
[07:55] <stub> Yeah, I don't think I can justify wasting time on it ;)
[07:55] <m_3> ack
[08:34] <stub> m_3: Do you recall if the PostgreSQL charm always required the database name to be set from the client end? http://jujucharms.com/charms/oneiric/oops-tools/hooks/db-relation-changed seems to expect it to be set by the server
[08:43] <m_3> stub: yes, iirc, the sequence is that the postgresql service creates a db w/ creds during relation-joined
[08:43] <m_3> then relation-sets that for the other side to you
[08:43] <m_3> it creates the db name based on the remove service name
[08:43] <m_3> that way multiple units of the same service get the same db
[08:44] <stub> m_3: So that would mean there is a bug in http://jujucharms.com/charms/precise/postgresql/hooks/hooks.py around line 1760?
[08:44] <m_3> lemme look
[08:45] <stub> oic.
[08:45] <stub> What is the syntax to set the database name from the command line then? juju set ... ?
[08:45] <m_3> yes
[08:46] <m_3> looking to see if there's a config param for that
[08:46] <m_3> there doesn't look to be one
[08:47] <m_3> and there shouldn't
[08:47] <m_3> whoops, I thought that was working on there
[08:47] <m_3> the sequence with a client is:
[08:48] <stub> So my understanding: there is a bug in the postgresql charm. At the moment it aborts if the database name isn't set on the relation. Instead, it is supposed to create a database based on the remote service name and inform the client.
[08:48] <m_3> juju deploy postgresql && juju deploy wordpress && juju add-relation wordpress postgresql
[08:48] <m_3> yes, that sounds right
[08:48] <m_3> so wordpress calls db-relation-joined which should be a no-op
[08:49] <m_3> postgresql calls db-relation-joined which creates database named "wordpress" and makes up user creds
[08:49] <m_3> does `relation-set` with all that info
[08:49] <m_3> wordpress calls db-relation-changed
[08:50] <m_3> if postgresql has sent the info, it uses it... otherwise, exits cleanly and waits to be called again
[08:50] <m_3> postgresql calls db-relation-changed which should be a no-ip
[08:51] <m_3> s/no-ip/no-op/ (that's my dns provider so's in muscle mem)
[08:51] <m_3> dang, I didn't realize that's been broken
[08:52] <stub> I'm writing my first client charm (so I can write tests) and was wondering why things were odd.
[08:52] <m_3> the postgresql's db-relation-joined hook needs to not _create_ a new db if it's already been created... it just sends the auth info back down the pipe
[08:53] <m_3> stub: that way multiple client units get the same database within the postgresql service
[08:53] <stub> right. Do you want me to fix the charm or do you want to repair it?
[08:53] <m_3> so if you want multiple clients talking to _different_ dbs... then the clients should have different service names
[08:53] <m_3> juju deploy wordpress blog1 && juju deploy wordpress blog2
[08:54] <m_3> then when those're related, we'd have two different dbs in pg
[08:54] <m_3> stub: It'd probably be better for you to do it
[08:54] <m_3> but I'm happy to if you'd rather
[08:55] <stub> I'll give it ago. I need it working so my charm client works ;)
[08:55] <m_3> thanks... wow, sorry didn't realize in review that that process was borked
[08:57] <stub> m_3: I suspect there is a charm somewhere relying on this behavior - specifying the database name to use
[08:57] <m_3> oh?  :(
[08:57] <m_3> we'll have to have a look at pgbouncer and friends too
[08:58] <m_3> hmmm.... wonder if it's worth trying to support either behavior
[08:58] <stub> I think we can have both behaviors, although we may end up with a spurious database if postgresql-charm creates a db then client-charm sets the database name
[08:58] <m_3> if we moved pg's creation logic into relation-changed
[09:00] <m_3> there's a bit of a problem there... ambiguity on what it means when the client is "silent"
[09:00] <m_3> does it mean the that client hasn't finished coming up yet?
[09:00] <m_3> or that it wants you to pick the db name for it?
[09:00] <stub> http://jujucharms.com/charms/precise/oops-tools/hooks/db-relation-joined
[09:01] <m_3> crap
[09:01] <stub> Cause there will be several different services needing to share the database.
[09:02] <m_3> right... that's still totally cool
[09:02] <m_3> based on service_name
[09:02] <m_3> new services get new dbs
[09:02] <stub> Different services with different names needing to share the database (because they need to share data)
[09:02] <m_3> oh oh, gotcha
[09:03] <stub> It is either that, or we require messing around with pgbouncer proxies and aliases and that seems more painful.
[09:03] <m_3> lemme look at oops... maybe we just need to support both behaviours
[09:03] <stub> So I'll see if I can support both uses.
[09:03] <m_3> the kicker is that we'll probably need to make mysql do the same thing
[09:04] <m_3> mysql does the 'db decides'
[09:04] <stub> Nah, mysql is for toy services ;)
[09:04] <m_3> haha
[09:04] <m_3> well I'm also wondering if we've copied that paradigm for mongodb, cassandra, etc
[09:05] <m_3> important to have them consistent
[09:05] <m_3> but supporting both behaviors seems worth trying
[09:05] <stub> I don't know if mongodb or cassandra have a similar way of partitioning data like PostgreSQL and its separate databases.
[09:06] <m_3> see if you can figure out how to differentiate "defaults" -vs- "relation-guard"
[09:06] <m_3> yeah, don't know if they create default keyspaces or leave that up to the client
[09:07] <m_3> relation-guard is what I call the "is the other side up yet?  go on... otherwise exit0"
[09:07] <m_3> remember changed keeps getting called as long as either side keeps doing relation-set
[09:10] <stub> Right. So pg's relation-changed and relation-joined are the same. So in this hook, if the database name isn't provided we generate it. If the database doesn't exist, we create it.
[09:10] <stub> And extra points for cleanup - if we generated a database that is not used by any active relations, nuke it.
[09:11] <stub> But a spurious empty database does no harm really.
[09:12] <m_3> we probably need to remove the "joined"
[09:12] <m_3> if it's reading anything from the other side, then that's really best done in changed exclusively
[09:12] <m_3> joined really should never try to read (it's only fired once)
[09:14] <m_3> either making it a no-op in code (exit 0) or just removing the hook (link) is equiv
[09:14] <stub> It needs a -joined hook to generate the default database in case the remote end doesn't want to specify it.
[09:14] <stub> So -joined generates a default database and -changed allows the client to override it.
[09:14] <m_3> oh, ack
[09:15] <m_3> yeah, that's probably workable... check the same "database" relation var
[09:15] <m_3> cool... I'll let you proceed
[09:15] <m_3> thanks man... nice catch
[09:20] <m_3> stub, m_3: just noting we need test cases for multiple client services _and_ multiple units of the same... using defaults as well as overriding db name
[09:21] <stub> ack
[09:50] <stub> This schema_user thing seems bogus too. A magic user is created with superpowers on the database, so every client using the charm gets superpowers on the database they connect to destroying any security you bother to set up with the normal user.
[11:28] <mgz> jamespage: I want review on mine and Mark's packaging updates to juju, should I just propose my branch for merging into raring? the catch is the history was kinda screwy so the mp diff will... not be useful
[11:29] <jamespage> mgz, yeah - thats OK
[11:29] <jamespage> or just pass me the branch
[12:39] <mgz> jamespage: have done everything and proposed, see lp:~gz/ubuntu/raring/juju/0.7 and mp
[12:58] <m_3> ugh... /me hates userpas
[13:04] <mgz> m_3: ^you probably also want to have a look at that branch, to see if I brought your changes in correctly
[13:04] <jamespage> mgz, m_3: some comment/fixes require - I'll doc them in the MP
[13:04] <mgz> jamespage: thanks!
[13:09] <m_3> jamespage: mgz: cool... hoping there's a better way than sed to get the version from rules into the postinst/prerm files
[13:10] <mgz> gah, and these test failures are new to me...
[13:10] <jamespage> m_3, ah - right
[13:10] <jamespage> thant answers one of my questions
[13:10] <jamespage> not that is not a great way todo it
[13:11] <m_3> mgz: yeah, I guess my use of 'DEB_BUILD_OPTIONS=nocheck' is a really bad habit
[13:12] <mgz> this is just something in my env, these ones were passing earlier...
[13:12] <mgz> not the most robust suite in the world
[13:12] <m_3> ack
[13:19] <mgz> okay, the branch is slightly borked...
[13:22] <jamespage> mgz, I had trouble getting the orig.tar.gz as well
[13:22] <mgz> gah, quilt, I hate you
[13:22] <jamespage> comments in the MP
[13:22] <jamespage> https://code.launchpad.net/~gz/ubuntu/raring/juju/0.7/+merge/158088
[13:22] <mgz> yeah, the rule for getting the tarball is borked... but it has been forever
[13:22] <mgz> and I didn't want to fix
[13:23] <mgz> thanks, those comments are useful
[13:26] <m_3> jamespage: yup, thanks
[13:27] <jamespage> m_3, mgz: if you do want to name the package juju-0.7 then we need to deal with transitions from juju -> juju-0.7
[13:27] <m_3> the prerm 'rm' might not be necessary with '--compile' in the rules... purge wasn't cleaning out that directory for some reason
[13:31] <m_3> jamespage: yeah, I guess I don't understand exactly how an upgrade would happen then... I thought it would remove old and install new, which should be fine with /usr/lib/juju-0.6 and /usr/lib/juju-0.7
[13:31] <mgz> jamespage: the plan is to add a meta-package I think
[13:32] <jamespage> m_3, for the files yes they would get automatically upgraded; but the alternatives will break
[13:32] <mgz> pushing a fix for the issue I noticed
[13:33] <jamespage> actually forget that - you use a prerm to remove the older version alternatives
[13:33] <jamespage> so its OK I think
[13:33] <jamespage> m_3: sorry - being dumb
[13:34] <m_3> jamespage: dude, I'm just barely caught up on this one... running through upgrade scenarios
[13:46] <jamespage> mgz, m_3: did I say to merge the 0.7 changelog entries?
[13:52] <mgz> jamespage: nope. I can do that
[13:53] <mgz> was a little confused as to the right thing, with ppas in the mix as well.
[13:53] <jamespage> mgz, ignore PPA changelog entries - only distro ones are relevant
[13:55] <m_3> jamespage: I assume '$< >' was an accidental autocomplete and not something strange required by dh?
[13:56] <jamespage> m_3: thats makefile magic
[13:56] <m_3> oh, nm... it's rhs and then redirect to file
[13:56] <m_3> doh
[13:56] <jamespage> $< is read-in dependency (in this case XX.in) and write out >
[13:56] <m_3> right
[13:57] <m_3> wasn't expecting the write out... my bad
[13:58] <m_3> wht a difference an '-i' makes :)
[14:00] <mgz> have pushed the changelog fix
[14:01] <mgz> m_3: are you working on the alternatives changes? you can either base off my branch, or I can pull in your parts when you're ready
[14:02] <m_3> mgz: I based off of your branch... pushing them one at a time to ~mark-mims/ubuntu/raring/juju/0.7
[14:03] <m_3> mgz: figure you can merge them and resubmit your branch
[14:04] <m_3> jamespage: mgz: any ideas why this won't purge cleanly unless the 'rm -Rf /usr/lib/python2.7/dist-packages/juju' is there?
[14:05] <jamespage> m_3 what error do you get?
[14:05] <m_3> take a bit to reproduce, but essentially it was a handful of "won't remove directory because it's not empy"
[14:05] <m_3> I sort of assumed it was .pyc files at the time, but that's not nec true
[14:06] <m_3> I'm sure it's cause I'm overriding dh_auto_install with
[14:06] <m_3> 'set -e && python setup.py install --root=debian/juju --install-layout=deb --install-scripts=/usr/lib/juju-$(VER)/bin --compile'
[14:07] <m_3> distutils magic that I'm missing by calling it manually
[14:12] <m_3> mgz: kicking off pbuilder to test the postinst/prerm changes
[14:20] <m_3> mgz: quilt's failing on that zookeeper patch
[14:21] <m_3> 0.6 still debuild's fine though
[14:22] <jamespage> mgz, m_3: you guys know about bzr merge-upstream right?
[14:22] <m_3> jamespage: um.... no
[14:23] <m_3> googling now
[14:24] <m_3> :)
[14:24] <m_3> I was tarring
[14:26] <mgz> jamespage: when the branch isn't horribly broken, yes
[14:27] <jamespage> mgz, is the last 0.6 update in the branch good?
[14:27] <mgz> it should work for any future upstream merges... but I needed to do some hacks
[14:28] <mgz> jamespage: nope. I could have based on the new minor 0.6.1 that I also fixed up, but really that's diverged
[14:29] <m_3> mgz: so all changes _other_ than manpages are in... just having problems getting past the borking patch atm
[14:29] <m_3> so they're untested
[14:37] <mgz> m_3: what is breaking for you exactly atm? we should possibly just add some more test skips for now.
[14:39] <m_3> mgz: http://paste.ubuntu.com/5695537/
[14:39] <m_3> from `debuild -us -uc -S`
[14:41] <mgz> ...internal error? let me try that locally. perhaps just refreshing the patch will help.
[14:42] <m_3> I'll clear and re-pull
[14:43] <m_3> damn that repo's big
[14:44] <mgz> I've been using `bzr builddeb -- -nc -us -uc` which works +- failing tests
[14:46] <m_3> crap... same thing with just your branch
[14:46] <m_3> juju-0.6 does fine though
[14:46] <m_3> ok, well lemme try with bzr bd
[14:54] <m_3> no love
[14:54] <m_3> got a call.. biab
[14:59] <mgz> m_3: I get a failure on your branch, but not mine, will see if I can fix
[15:01] <m_3> mgz: sorry, I don't relly know what's going on with .pc
[15:01] <m_3> I assume it's where it's applying the patches or something
[15:01] <mgz> yeah, that's all quilt related
[15:04] <mgz> m_3: what I get <http://paste.ubuntu.com/5695604/>
[15:06] <m_3> mgz: yikes
[15:06] <mgz> m_3: try `quilt pop -a` then `quilt push -a`
[15:07] <m_3> mgz: ok, so I've gotta get some other bits into the rules
[15:08] <m_3> dang... did the pop and push and it's still failing
[15:51] <mgz> m_3: so, with your commit of the .in files and one more fix, I get a build package: lp:~gz/ubuntu/raring/juju/mims
[15:52] <m_3> mgz: oh, whew... that error was when the .in files were missing
[15:52] <m_3> mgz: good, was scared by that error otherwise
[15:53] <mgz> I'll fixup that and put it in my branch. what have we got left, the man pages?
[15:54] <m_3> mgz: yeah, I wanted to test the .in changes
[15:54] <m_3> mgz: and then figure out how to do the manpages
[15:55] <m_3> no clue how to version them for alternatives though
[15:55]  * m_3 can look at java or something
[15:57] <m_3> mgz: I was wondering what vim's problem was with the syntax on rules... good catch
[15:58] <mgz> m_3: those fixes are now brought across to lp:~gz/ubuntu/raring/juju/0.7
[15:59] <m_3> mgz: oh, great... I'll rebase
[15:59] <m_3> thanks!
[15:59] <mgz> (cherrypicked rather than merged so the fileids stayed the same)
[16:00] <m_3> ack
[16:08] <m_3> mgz: argh... no love... the new branch is still doing the same thing for me
[16:09] <m_3> I give up trying to build it
[16:09] <m_3> lemme quit screwing with that and see if I can get manpages versioned
[16:12] <mgz> you can just `rm -rf .pc` if that helps
[16:12] <mgz> easy enough to get back the state with `bzr revert .pc` after if you're not actually touching the patches
[16:18] <m_3> still same thing w/o the .pc file /me doesn't know wtf
[16:22] <mgz> hm, I wonder if it's actually the dsc that's borked. try removing that and the -nc flag if you're still using it?
[16:23] <m_3> yeah, I just cleaned everything up
[16:23] <m_3> noted that I had some 0.6 stuff in the higher directory
[16:27] <m_3> mgz: hey, should I cut the .pc stuff out of the upstream tarball?
[16:27] <m_3> I'm just creating it from the repo directly w/ no changes
[16:28] <mgz> it certainly shouldn't be in the upstream tarball
[16:28] <m_3> ah... ok
[16:28] <mgz> the upstream tarball is what you get from lp:juju/0.7 and bzr export
[16:29]  * m_3 facepalm... sorry man
[16:30] <mgz> it's okay, the tooling for this is slightly borked in the branch as jamespage mentioned earlier...
[16:30] <m_3> now that makes sense as to why quilt wasn't happy
[16:30] <m_3> it puts patches on _top_ of the upstream tarball
[16:31] <mgz> I'll have another quick look at resolving that
[16:33] <m_3> mgz: whoohooo!
[16:33] <m_3> that worked
[16:33] <m_3> ok, wife's waiting on me for dinner... I'll test out alternatives chagnes, figure out how to get manpages in
[16:34] <m_3> have a branch for you in the morning?
[16:34] <imbrandon_> robbiew: arnt you in Austin? I hear its the next city to get Google Fiber ;)
[16:34] <robbiew> yeeeeeep!
[16:34] <mgz> m_3: sounds great
[16:34] <m_3> mgz: might be able to get it sooner... lemme see how long dinner goes
[16:35] <m_3> whew
[16:35] <m_3> now I can build again :)
[16:35] <m_3> ok, I'm out for abit
[16:35] <imbrandon_> robbiew: I'm telling ya now, goto the http://google.com/fiber page and put your address in for pre-registration , you'll be glad you did … it filled here FAST
[16:36] <imbrandon_> heh
[16:37] <imbrandon_> robbiew: yup, here is the exact link, and Austin is now listed … https://fiber.google.com/cities/#header=check
[16:38] <robbiew> imbrandon_: already did
[16:38] <imbrandon_> :)
[16:40] <mgz> m_3: fixed the get-orig-source rule
[16:52] <mattgriffin> jcastro, arosales: i've got some questions about the Charm Store but need to get off of the hangout and run to lunch. i'll ping you later today. thanks!
[16:52] <jcastro> ok
[16:53] <arosales> mattgriffin: ok, thanks for joining us.
[17:36] <niemeyer> % juju publish cs:~niemeyer/precise/build-mongo
[17:36] <niemeyer> cs:~niemeyer/precise/build-mongo-0
[17:36] <niemeyer> !
[19:00] <arosales> jcastro: thanks for sending out the charm meeting minutes, nice summary
[19:02] <jcastro> yeah it turned out not as crappy as I thought
[19:03] <jcastro> I'll make them more interesting once I get used to it
[19:52] <jadams> anyone here played with the openstack packages?  I'm a bit confused on the 'quantum' networking stuff
[21:10] <mattgriffin> jcastro, arosales: ping … got some questions about the Charm Store. have a sec?
[21:36] <arosales> mattgriffin: hello, sure
[21:37] <arosales> mattgriffin: sorry the delayed response. I was grabbing some lunch.
[21:41] <mattgriffin> arosales: np. are there any plans to support some kind of a feedback loop for Charms usage - either quantitative or qualitative - back to the author?
[21:42] <arosales> mattgriffin: besides a bug report a method for continuos feedback
[21:43] <arosales> mattgriffin: there is https://juju.ubuntu.com/docs/charm-quality.html that we are working on "rating" for each charm
[21:43] <arosales> but that isn't really continuous feedback, and mostly from the LP charmers group and not from users.
[21:44] <arosales> mattgriffin: aside from bugs were you thinking of comments on the charm page, or a forum, or something else?
[21:45] <arosales> mattgriffin: also the metadata.yaml does have the authors contact info, at least for charms that have maintainers . . .
[21:45] <arosales> mattgriffin: in terms of quantitative feedback we are also working on display the charm "usage" or download statistics from the charm store.
[21:46] <mattgriffin> arosales: yeah… feedback could be interest measured by downloads (not really possible), ratings from Charm Store managers (your link), +1's/likes by users, qualitative feedback/praise/reviews by users, and an easy way to submit bugs
[21:47] <mattgriffin> arosales: so the purpose would be to help Charm browsers make better decisions and also help Charm authors with feedback on interest in their Charm and ideas to make it better
[21:48] <mattgriffin> arosales: ah… download stats … very interesting
[21:50] <mattgriffin> arosales: when might the quantitative feedback measures be available?
[21:50] <mattgriffin> arosales: stats i mean
[21:51] <arosales> mattgriffin: hopefully by 13.04, so soon
[21:51] <arosales> mattgriffin: I like your ideas on feedback
[21:51] <arosales> shows in the charm page
[21:51] <arosales> what ways did you envision, "feedback/praise/reviews by users"
[21:51] <arosales> comments? forums?
[21:52] <arosales> s/shows/shown/
[21:52] <mattgriffin> arosales: yeah. something similar to consumer app store feedback - short and sweet … and maybe easily tweet.
[21:53] <arosales> mattgriffin: ya so we need some more social networking integration into the charm page.
[21:53] <mattgriffin> arosales: perhaps be able to leverage some of the reviews infrastructure (or learnings) from USC
[21:54]  * arosales makes note for a blueprint for "adding social networking to Charm Store charm pages."
[21:54] <arosales> mattgriffin: good point on USC
[21:56] <arosales> mattgriffin: aside from download stats any other quantitative information you would be interested in?
[21:57]  * mattgriffin thinks
[21:59] <mattgriffin> arosales: some indication of the age or update frequency might be helpful in selecting a charm… i don't know … might be reaching on that one
[22:00] <arosales> mattgriffin: perhaps recent commits, and age in the charm store
[22:02] <mattgriffin> arosales: :) cool
[22:07] <arosales> mattgriffin: just some ideas on information that is there, but may be interesting to users . .
[22:07] <arosales> mattgriffin: good stuff, I think there is some good ideas there for a blueprint.
[22:09] <mattgriffin> :)
[22:25] <arosales> mattgriffin: please add any ideas that come up into  https://blueprints.launchpad.net/ubuntu/+spec/servercloud-1305-juju-charmstore-feedback-loops
[22:26] <arosales> mattgriffin: be good to see virtually see you at http://summit.ubuntu.com/uds-1305/ too
[23:48] <mattgriffin> arosales: cool. will do


[12:50] <klaidas_> @schedule Vilnius
[12:50] <Ubugtu> Schedule for Europe/Vilnius: 02 Jan 22:00: Technical Board | 03 Jan 22:00: Edubuntu | 04 Jan 00:00: Xubuntu | 04 Jan 18:00: Ubuntu Development Team | 09 Jan 17:00: LoCo Team | 09 Jan 18:00: Forum Council
[12:55] <freeflying|away> @schedule shanghai
[12:55] <Ubugtu> Schedule for Asia/Shanghai: 03 Jan 04:00: Technical Board | 04 Jan 04:00: Edubuntu | 04 Jan 06:00: Xubuntu | 05 Jan 00:00: Ubuntu Development Team | 09 Jan 23:00: LoCo Team | 10 Jan 00:00: Forum Council
[12:58] <freeflying|away> @schedule shanghai
[12:58] <Ubugtu> Schedule for Asia/Shanghai: 03 Jan 04:00: Technical Board | 04 Jan 04:00: Edubuntu | 04 Jan 06:00: Xubuntu | 05 Jan 00:00: Ubuntu Development Team | 09 Jan 23:00: LoCo Team | 10 Jan 00:00: Forum Council
[06:17] <siretart> @schedule Europe/Berlin
[06:17] <Ubugtu> Schedule for Europe/Berlin: 02 Jan 21:00: Technical Board | 03 Jan 21:00: Edubuntu | 03 Jan 23:00: Xubuntu | 04 Jan 17:00: Ubuntu Development Team | 09 Jan 16:00: LoCo Team | 09 Jan 17:00: Forum Council
[09:00] <siretart> TB Meeting anyone?
[09:00] <Keybuk> Never Fear, I Is Here
[09:00] <siretart> hey Keybuk  :)
[09:00] <Keybuk> do we have mdz, mjg59 or sabdfl?
[09:01] <ogra> doesnt look like
[09:01] <siretart> mjg59 seems to be on #ubuntu-devel, no idea about mdz and sabdfl
[09:02] <siretart> Keybuk: did my inquiry arrive on<EMAIL_ADDRESS>I didn't get any response yet
[09:02] <Keybuk> it did, yes
[09:02] <siretart> okay
[09:02] <Keybuk> the lack of response is almost certainly related to the holiday season
[09:02] <siretart> I thought so, no problem
[09:02] <siretart> I wasn't sure about correct arrival either
[09:03] <mjg59> Tch. I was sure I had this on autojoin.
[09:05] <Keybuk> ok
[09:05] <Keybuk> let's get started
[09:05] <Keybuk> mdz is on holiday, and has no internet access
[09:05] <Keybuk> so it's just the two of us today
[09:05] <mjg59> Right
[09:05] <Keybuk> first, some administrivia
[09:05] <mjg59> Anyone for core-dev?
[09:05] <mjg59> Ah, ok
[09:06] <Keybuk> people will note that it's been two years since we started using LP to track developers
[09:06] <Keybuk> so we're starting to get people's team membership expire
[09:06] <Keybuk> if you're an active developer, you'll be renewed automatically
[09:06] <Keybuk> if you haven't been active for a while, you may need to reapply via TB meeting again
[09:07] <siretart> how is the 'activeness' measured? by a human or by soyuz looking at the last upload?
[09:07] <Keybuk> human
[09:07] <siretart> k
[09:08] <Keybuk> one of the TB members will react to the "seb128 has expired!" e-mail, and renew the membership :)
[09:08] <ogra> do trhe users get them too ?
[09:08] <Keybuk> yes
[09:08] <ogra> to have the ability to raise their hands  ?
[09:08] <ogra> ah, cool
[09:09] <ogra> i had some for edubuntu recently
[09:09] <Keybuk> anyway, onwards
[09:09] <Keybuk> core-dev
[09:09] <Keybuk> I have nobody in my list
[09:09] <Keybuk> is there anybody here who's applied for core-dev membership and thinks they should be?
[09:10] <Keybuk> clearly not
[09:10] <Keybuk> good
[09:11] <Keybuk> ubuntu-dev
[09:11] <Keybuk> again, I have nobody in my l.ist
[09:11] <Amaranth> https://launchpad.net/people/ubuntu-core-dev/+members shows 4 people
[09:11] <Keybuk> is there anybody here who's applied for ubuntu-dev membership and thinks they should be?
[09:11] <ogra> why is kylem on there ?
[09:11] <Keybuk> Amaranth: we only consider people who applied since the last TB meeting
[09:11] <Amaranth> ah, i see
[09:11] <ogra> he should be uploading already, shouldnt he ?
[09:12] <Keybuk> those that applied before are people who were turned down at a previous meeting with a "later"
[09:12] <Keybuk> ogra: playing "join all teams", I expect
[09:12] <ogra> heh
[09:13] <Keybuk> ok
[09:13] <Keybuk> nobody for ubuntu-dev today then
[09:13] <kylem> ogra, i didn't read far enough that core-dev implied -dev.
[09:13] <Keybuk> dholbach isn't around, so I assume we will not be discussing Council Greyskull today
[09:13] <ogra> well, no quorum anyway
[09:14] <Keybuk> siretart: you have an agenda item, the floor is yours
[09:14] <Keybuk> ogra: we have Q
[09:14] <ogra> two is enough ?
[09:14] <ogra> ah, right, its TB :) not CC
[09:14] <Keybuk> ogra: yes, TB Q has always been two
[09:14] <siretart> well, status update: I have contacted the techincal board again, this time via email about the ffmpeg issue
[09:14] <Keybuk> we assume a three man team, and require a simple majority
[09:15] <siretart> I filed a MIR about ffmpeg, requested it to be reapproved for main
[09:15] <Keybuk> yes
[09:15] <Keybuk> I didn't get the context of the e-mail
[09:15] <siretart> I'm still not sure what codecs are exactly problematic
[09:16] <siretart> until that issue is resolved, I'm proposing an interim solution: let's upload xine-lib with its internal partial copy of ffmpeg with no mpeg2 encoding capabilities
[09:16] <siretart> to main that is
[09:16] <Keybuk> what uses xine-lib?
[09:16] <mjg59> Ok. So I've a couple of questions about this, to begin with.
[09:16] <siretart> since we already have packages like libmad, I'd like to know what issues are to resolve
[09:17] <siretart> Keybuk: most notable kubuntu (amarok) and xubuntu
[09:17] <mjg59> 1) Is mpeg2 the only actively-enforced-patent-encumbered codec in ffmpeg?
[09:17] <ogra> Keybuk, totem-xine
[09:18] <mjg59> We're getting very close to the point where we should drop totem-xine, but that's not strictly important
[09:18] <siretart> mjg59: 1) I refer to debian/patents.txt quoted on https://wiki.ubuntu.com/MainInclusionFFmpeg. Sam (and me neither) don't know about any further
[09:18] <Keybuk> ogra: don't we support totem-gstreamer instead?  and the theory of ffmpeg-in-main was that some of the ugly codecs could be in main too?
[09:18] <siretart> Keybuk: gxine as well
[09:18] <ogra> Keybuk, right, totem-xine isnt in main either, sorry
[09:19] <siretart> Keybuk: xine uses ffmpeg not only for codecs. some plugins use the 'libpostproc' library, which has nothing to do about decoding. I expect some other packages as well
[09:19] <mjg59> siretart: I'm not sold on the "libmad is in main, so ffmpeg should be"
[09:19] <mjg59> It's equally plausible that libmad being in main is an error
[09:20] <mjg59> We quite clearly don't ship a useful mp3 player in main, and that's defined as policy
[09:20] <siretart> mjg59: demotion of libmad would cause quite some trouble, looking at the reverse build-deps
[09:20] <Keybuk> http://people.ubuntu.com/~cjwatson/germinate-output/feisty/rdepends/libmad/libmad0
[09:21] <siretart> mjg59: anyway, if the decision is to demote libmad, then I'd request to demode xine-lib as well. this would however deeply annouy kubuntu and xubuntu users
[09:21] <Keybuk> I'm not sure why it's still a build-depend
[09:21] <Mithrandir> mjg59: *cough*; xmms *cough*
[09:21] <zul> Mithrandir: er...its still kind of brroken
[09:21] <mjg59> Mithrandir: Seriously? That can't be deliberate.
[09:22] <Mithrandir> mjg59: done so since warty.
[09:22] <mjg59> Sigh.
[09:22] <mjg59> Ok.
[09:22] <Keybuk> note that main != CD
[09:22] <mjg59> Let's just ignore the current state of reality. It clearly isn't useful.
[09:22] <Mithrandir> it might very well be an error, but we quite clearly do, just not in a default install.
[09:22] <Keybuk> we certainly don't ship any MP3 players on the CD
[09:22] <Keybuk> that's definitely legally naughty
[09:23] <mjg59> Right. So.
[09:23] <Keybuk> on the FTP site is legally wishy-washy because users initiate the download
[09:23] <siretart> as mentioned, I have already prepared new xine 1.1.3 packages, with the ffmpeg plugin split out to libxine1-ffmpeg. Xine loads its plugins at runtime using dlopen, which makes this convinient
[09:23] <mjg59> Keybuk: Do we have legal advice on that?
[09:23] <Keybuk> mjg59: that's my understanding, otherwise we wouldn't ship them in universe
[09:23] <siretart> so even if we promote ffmpeg and xine-lib uses that, we don't need to put ffmpeg on the CD
[09:23] <Keybuk> my understanding is that main vs. universe is legally no different, but CD vs. FTP is
[09:24] <siretart> this was an argument in my email, right
[09:24] <mjg59> Keybuk: Ok. You're in a better position to check that than I am - is it possible to verify that, just to make sure that we're not doing it unwittingly?
[09:24] <Keybuk> main vs. universe is simply a matter of which team (core-dev vs. dev) supports the package
[09:24] <mjg59> Right, clearly there's no legal distinction between main, universe and multiverse
[09:25] <Riddell> people may assume that since main is supported it can be freely used without worrying about getting a patent licence
[09:25] <Riddell> (or they may not)
[09:25] <mjg59> So based on current practice, providing a xine-lib including ffmpeg would be fine for main, just not for ship
[09:25] <Keybuk> mjg59: previous legal issues have been somewhat clouded by people shouting "WE'RE GOING TO JAIL!" over the top of sensible discourse  ;)
[09:25] <Keybuk> mjg59: assuming that xine-lib, xmms, etc. aren't in main by mistake :p
[09:26] <Keybuk> none of them are seeded, so I'd be willing to believe an FTP master was especially asleep one day
[09:26] <Riddell> we need xine-lib
[09:26] <mjg59> Keybuk: Well, that pretty much definitely would be "aren't on the FTP server by mistake"
[09:26] <Riddell> and xmms is orders of sabdfl I believe
[09:26] <Keybuk> but yes, given that xmms and libmad are in main, I don't see the reason that ffmpeg isn't
[09:26] <mjg59> I'm going to attempt to summarise this, and propose the next step.
[09:27] <Keybuk> siretart has filed an MIR, that's a request for the archive admins to promote it
[09:27] <siretart> xmms and ffmpeg are pretty unrelated. xmms uses libmad, which bring in the same legal concers as ffmpeg though
[09:27] <Keybuk> actually
[09:27] <Keybuk> sorry
[09:27] <Keybuk> that's a request for the security team to review it
[09:27] <Keybuk> so the next step is for pitti or keescook to review the source to determine whether we can provide security support for ffmpeg
[09:27] <mjg59> (*) Current policy appears to be that patent-encumbered code may be distributed in main, but not in ship.
[09:27] <Keybuk> if they approve it, then it's a request for the archive admins to promote it once it has been seeded
[09:27] <Keybuk> anyone in core-dev can modify the seeds
[09:28] <Keybuk> mjg59: that is my understanding, yes
[09:28] <mjg59> (*) Based on this, it would be reasonable for a version of xine-lib containing ffmpeg code to be in main. However, any package that becomes part of ship must *not* contain this code.
[09:28] <siretart> I don't think anyone not in the desktop team dares to touch the seeds ;)
[09:28] <Keybuk> siretart: hmm, most of core-dev have touched them ?
[09:29] <siretart> aha? - interesting :)
[09:29] <mjg59> (*) Therefore, assuming the accuracy of the first observation, the TB has no reason to deny the inclusion of ffmpeg code in main *providing* that the technical implementation allows the ffmpeg code to be split from the core xine-lib binary package
[09:30] <Keybuk> it may be worth posting that as a summary, and requesting the Community Council's input
[09:30] <siretart> mjg59: I assume you mean 'binary code' and not 'source code' here
[09:30] <mjg59> (This is predicated upon the accuracy of the first observation. The TB should also internally determine that adequate legal advice has been obtained by Canonical)
[09:30] <mjg59> siretart: Either
[09:31] <Keybuk> I would also add:
[09:31] <Mithrandir> having stuff in main we can't ship on the CDs is a bit bad since people can easily end up including it by mistake by promoting something else.
[09:32] <mjg59> Mithrandir: This situation already exists. We should ensure that it is hard.
[09:33] <mjg59> If you feel it's practical, I'd be happy for us to suggest that it be a requirement that the archive allow packages to be tagged as "not ship", or something similar
[09:33] <Keybuk> (*) This constitutes a recommendation of the TB, however this recommendation is not binding and the Archive Administrators are permitted to deny this.
[09:33] <siretart> like putting the binary package 'ffmpeg' (ffmpeg command line utilities) and libxine1-ffmpeg
[09:33] <siretart> to universe?
[09:33] <mjg59> Having libxine1-ffmpeg in main should be fine
[09:34] <Keybuk> why would having ffmpeg in main be not fine?
[09:34] <mjg59> It's just important that it never somehow end up in ship
[09:34] <Keybuk> they're useful utilities
[09:34] <siretart> indeed, they are
[09:35] <mjg59> Keybuk: Do you want to mail this to people, or shall I?
[09:35] <Keybuk> mjg59: can you
[09:35] <mjg59> Ok
[09:35] <mjg59> Anyone have anything else to add?
[09:35] <siretart> yes
[09:35] <Keybuk> siretart: your next step, anyway, is to talk to pitti and keescook and have the MIR approved
[09:35] <siretart> I'd like an answer to my interim proposal
[09:35] <Keybuk> regardless of any patent issues, you need their approval
[09:35] <Keybuk> I don't see how your interim proposal helps anything?
[09:35] <siretart> read: upload xine-lib and make it use the internal (decoding only) copy
[09:36] <siretart> Keybuk: it allows having xine-lib 1.1.3 sooner in the archive
[09:36] <Keybuk> is there a critical or urgent bug this fixes?
[09:36] <siretart> allowing Riddell to upload a newer amarok
[09:36] <mjg59> siretart: Given what we've concluded, I don't see any reason for that to be something we need to cover here
[09:36] <siretart> and buying us additional testing
[09:36] <mjg59> Do whatever you think is best
[09:36] <mjg59> With the previous proviso of ensuring that ffmpeg code never appears in ship
[09:36] <Keybuk> amarok is shipped
[09:37] <siretart> I think uploading with ffmpeg is best for ubuntu, so we finally get goodies like WMV9 on amd64 :)
[09:37] <Keybuk> it's part of ubuntu-desktop
[09:37] <Keybuk>              ^
[09:37] <Keybuk>              k
[09:37] <Keybuk> so that's forbid, under our current reading
[09:37] <mjg59> siretart: Would the ffmpeg code be in a separate binary package?
[09:37] <siretart> Keybuk: that's no problem. the ffmpeg code in libxine1-ffmpeg does not need to be in ship. amarok just depends on libxine1
[09:37] <mjg59> I believe you implied it would be
[09:37] <siretart> mjg59: yes, I already have such packages ready
[09:37] <mjg59> Yes, then that's fine. Just ensure that nothing depends on libxine1-ffmpeg.
[09:38] <siretart> as seen in https://code.launchpad.net/people/siretart/+branch/xine-lib/xine-lib.ubuntu.1.1.3
[09:38] <siretart> yepp, willdo
[09:38] <mjg59> Ok. I think we're done with this.
[09:38] <siretart> thanks
[09:38] <Keybuk> you may want to check the new source with pitti/keescook
[09:38] <Keybuk> especially if it contains a complete copy of ffmpeg
[09:39] <Keybuk> just to make sure it wasn't removed for security reasons
[09:39] <Keybuk> ok, that's the end of the agenda on my screen
[09:39] <Keybuk> any other business?
[09:40] <Keybuk> ok, done
[09:40] <Keybuk> unless we hear a scream from elmo at this point
[09:41] <mjg59> Right. I'll email a summary.
[09:41] <Keybuk> thanks
[09:41] <Keybuk> I'd mail it to the TB and CC
[09:42] <siretart> well, he (as debian ftpmaster) has approved it for debian/main
[09:42] <mjg59> Keybuk: Do I want to mail archive admins?
[09:42] <siretart> at least, he didn't object
[09:42] <Keybuk> can do
[09:42] <Keybuk> siretart: the Debian package has had all of the encoding ripped out, no?
[09:42] <mjg59> Do we have a list for them?
[09:43] <Keybuk><EMAIL_ADDRESS>[09:43] <siretart> Keybuk: not all. the 'problematic' ones (to the best knowledge of the package maintainer)
[09:43] <Robot101> siretart: as a slight aside, do you know how this list of "problematic" encoders was arrived at?
[09:44] <siretart> Robot101: see my mir. the files README.Debian and patents.txt do have a nice summary
[10:19] <Keybuk> mjg59: nice summary
[10:19] <Keybuk> personally I'd like to just enable mp3 support in main once and for all :)
[10:19] <somerville32> :]
[10:20] <mc44> Keybuk: only have to wait till 2011 :)
[10:26] <siretart> Keybuk: mp3 encoding or decoding support?