[00:01] <cherylj> alexisb: "cannot determine machine endpoint bindings: endpoint bindings
[00:01] <cherylj>       for "s#dummy-source" not found'"
[00:01] <cherylj> alexisb: not sure what that means in terms of their code change, though
[00:02] <alexisb> ok
[00:50] <davecheney> 2016-02-02 00:47:47 ERROR juju.worker runner.go:229 exited "toolsversionchecker": cannot update tools information: cannot get latest version: cannot find available tools: cannot read product data, invalid URL "https://juju-dist.s3.amazonaws.com/tools/streams/v1/com.ubuntu.juju:released:tools.sjson" not found
[00:51] <davecheney> 2016-02-02 00:47:55 ERROR juju.worker runner.go:229 exited "toolsversionchecker": cannot update tools information: cannot get latest version: cannot find available tools: cannot read product data, invalid URL "https://juju-dist.s3.amazonaws.com/tools/streams/v1/com.ubuntu.juju:released:tools.sjson" not found
[00:51] <davecheney> is it _really_ necessary to poll for new tools every 8 seconds
[00:55] <cherylj> juju has OCD
[01:17] <davecheney> honestly ,checking once and hour would be overkill
[01:40] <davecheney> thumper: https://github.com/juju/juju/pull/4259
[01:40] <davecheney> pprof PR for review
[01:45] <davecheney> i wish the juju deployer hadn't stopped working
[01:45] <davecheney> i know people tell me that i'm using an outdated versin
[01:45] <davecheney> but frankly, if we (juju) have to live in a world where we have to keep making the versino in trusty work for the next 3 years
[01:45] <davecheney> then the same should apply to the deployer
[01:51] <mwhudson> axw: do you know things about azure?
[01:55] <davecheney>   File "/usr/lib/python2.7/dist-packages/deployer/env/go.py", line 96, in get_cli_status
[01:55] <davecheney>     status = super(GoEnvironment, self).get_cli_status()
[01:56] <davecheney> cherylj: thumper who changed the default juju status to be _not_ yaml
[01:56] <davecheney> that has broken the juju-deployer shipped in trusty
[01:58] <davecheney> yup, that's the problem
[01:58] <davecheney> cherylj: where should I log this bug ? against juju
[01:58] <davecheney> or against the deployer that it needs to call juju status with an explicit formatter ?
[02:00] <davecheney> https://bugs.launchpad.net/juju-core/+bug/1540697
[02:00] <mup> Bug #1540697: Recent change to juju status has broken compatibility with trusty juju-deployer <juju-core:New> <https://launchpad.net/bugs/1540697>
[02:05] <axw> mwhudson: I do, sorry, missed your message
[02:05] <mwhudson> axw: heh you answered the thread anyway
[02:07] <axw> davecheney: the (informal) plan for 2.0 is that anyone who needs structured output needs to explicitly specify the format
[02:07] <axw> davecheney: otherwise you get tabular, and its format might change over time
[02:08] <natefinch> wallyworld, axw: git blame says you guys might know about the implementation of deploying bundles with juju core?
[02:08] <axw> so long as that holds, deployer needs to be changed
[02:08] <axw> natefinch: I know some, I added storage support
[02:08] <mwhudson> i guess deployer in trusty needs to be sru-ed then?
[02:08] <wallyworld> natefinch: francesco did the work, we tweaked as needed
[02:09] <natefinch> wallyworld: is it me, or do we just drop all the flags (except storage) on the floor if you target a bundle?
[02:09] <mup> Bug #1540697 opened: Recent change to juju status has broken compatibility with trusty juju-deployer <juju-core:New> <https://launchpad.net/bugs/1540697>
[02:09] <wallyworld> davecheney: deployer in trusty will work with 1.25
[02:09] <wallyworld> tht is our mandate
[02:10] <axw> natefinch: which flags?
[02:10] <wallyworld> 2.0 will be co-installable with 1.25 andf 1.25 wil be supported for 2 years
[02:10] <natefinch> axw: juju deploy flags
[02:10] <wallyworld> 2.0 will not be backwards compatible
[02:10] <wallyworld> we will support juju in trusty via 1.25
[02:11] <natefinch> axw: like --constraints -n --networks etc ... looking at the code, it seems like we woudl totally let you 'juju deploy cs:/bundle/foo/bar --constraints=blah' and not complain, but completely ignore the constraints
[02:12] <natefinch> axw: it's the "not complain" part that bothers me
[02:12] <axw> natefinch: looks a bit like it. I'd say because it kind of changes the meaning of deploy entirely. not one service, but multiple
[02:12] <axw> natefinch: yeah
[02:12] <axw> we should error if you specify them
[02:12] <natefinch> axw: exactly my thinking
[02:13] <axw> natefinch: I added a bundle-specific syntax to the --storage command that allows you to specify for services in a bundle. we probably should do that for other things, but erroring would be a good start
[02:14] <natefinch> axw: yep.  ok, just wanted to make sure I wasn't missing anything obvious before filing a bug
[02:25] <davecheney> wallyworld: ahh, ok
[02:25] <davecheney> thumper: http://paste.ubuntu.com/14854594/
[02:26] <wallyworld> davecheney: we shoudl try and make deployer work though if possible i think. 2.0 has deployer built in but i don't think it is yet fully functionally complete
[02:26] <davecheney> this is on a modest sized deployment
[02:26] <davecheney> wallyworld: it's a trivial chang to the deployer
[02:26] <davecheney> but that has to be backported to trusty
[02:26] <davecheney> which is not trivial
[02:26] <thumper> davecheney: nice
[02:26] <wallyworld> davecheney: it is - my other concern is that in 2.0 old yaml fields like agent0state are gone
[02:26] <davecheney> thumper: i'm going to commit this and backport it
[02:26] <davecheney> so we can investigate that failure
[02:26] <thumper> ack
[02:27] <wallyworld> so deployer may need subsequent tweaking
[02:29] <davecheney> precise environments still have two mongodbs installed ...
[02:29] <davecheney> root@ip-10-250-24-28:/tmp# ps auxww | grep mongo
[02:29] <davecheney> mongodb   5462  0.6  0.9<PHONE_NUMBER>4 ?        Ssl  01:48   0:15 /usr/bin/mongod --config /etc/mongodb.conf
[02:29] <davecheney> root      6410  3.2  1.2 3026932 46808 ?       Ssl  02:28   0:01 /usr/bin/mongod --auth --dbpath /var/lib/juju/db --sslOnNormalPorts --sslPEMKeyFile /var/lib/juju/server.pem --sslPEMKeyPassword xxxxxxx --port 37017 --noprealloc --syslog --smallfiles --journal --keyFile /var/lib/juju/shared-secret --replSet juju --ipv6 --oplogSize 512
[02:29] <davecheney> root      6511  0.0  0.0   8100   932 pts/1    S+   02:29   0:00 grep --color=auto mongo
[02:29] <davecheney> our mongob does not restart if the process dies for any reason :(
[02:30] <thumper> really?
[02:30] <thumper> isn't that what upstart or systemd does?
[02:30] <davecheney> kill 6410
[02:30] <davecheney> process does not restart
[02:32] <davecheney> root@ip-10-250-24-28:/tmp# initctl list | grep juju
[02:32] <davecheney> juju-db stop/waiting
[02:32] <davecheney> juju-clean-shutdown stop/waiting
[02:32] <davecheney> jujud-machine-0 start/running, process 5548
[02:32] <davecheney> process does not restart
[02:39] <mup> Bug #1512718 changed: Leader election fails with "leadership failure: leadership manager stopped" <arm64> <landscape> <sts> <juju-core:Triaged> <juju-core 1.24:Triaged> <juju-core 1.25:Incomplete> <https://launchpad.net/bugs/1512718>
[02:39] <mup> Bug #1540697 changed: Recent change to juju status has broken compatibility with trusty juju-deployer <juju-core:Invalid> <juju-deployer:New> <https://launchpad.net/bugs/1540697>
[02:39] <mup> Bug #1540701 opened: juju deploy <bundle> silently ignores most CLI flags <bundles> <deploy> <juju-core:New> <https://launchpad.net/bugs/1540701>
[02:40] <thumper> wallyworld: under which situation will a service not have a status doc?
[02:40] <wallyworld> thumper: never; there ws a bug in an early 1.24(?) release where that could have been the case
[02:41] <thumper> wallyworld: so I can assume that there will always be a status doc for services?
[02:41] <thumper> for migration?
[02:41] <wallyworld> yep
[02:41] <thumper> awesome
[02:41] <thumper> ta
[02:41] <wallyworld> the status doc is written first
[02:41] <wallyworld> in the []txn.Ops slice
[02:42] <thumper> kk
[02:55] <davecheney> thumper: master is blocekd
[02:55] <davecheney> can I have your permission to land this change ?
[03:12] <davecheney> thumper: and environment with 11 machines, has 51 firewall watchers running
[03:12] <thumper> 51?
[03:12] <thumper> wow
[03:12] <davecheney> no, sorry,
[03:12] <davecheney> 20 @ 0x437c2a 0x446482 0x445472 0xa3f46f 0xa40234 0xd53b36 0x464e41
[03:12] <davecheney> #	0xa3f46f	github.com/juju/juju/worker/firewaller.(*machineData).watchLoop+0x43f		/home/dfc/src/github.com/juju/juju/worker/firewaller/firewaller.go:767
[03:12] <davecheney> #	0xa40234	github.com/juju/juju/worker/firewaller.(*Firewaller).startMachine.func1+0x44	/home/dfc/src/github.com/juju/juju/worker/firewaller/firewaller.go:243
[03:12] <davecheney> #	0xd53b36	github.com/juju/juju/worker/catacomb.Invoke.func3+0x76				/home/dfc/src/github.com/juju/juju/worker/catacomb/catacomb.go:115
[03:12] <davecheney> 20
[03:13] <davecheney> we do have 58 moingodb conections in use
[03:13] <davecheney> http://paste.ubuntu.com/14854643/
[03:13] <davecheney> it's just a bloodbatch
[03:13] <davecheney> it's just a bloodbath
[03:13] <davecheney> and this environment is idle
[03:15] <thumper> davecheney: I've added my mark on the github PR
[03:16] <thumper> davecheney: try to land it now
[03:34] <davecheney> ta
[03:42] <davecheney> cmd/pprof/pprof.go:61:2: cannot find package "runtime/trace" in any of: /usr/lib/go/src/pkg/runtime/trace (from $GOROOT) /mnt/jenkins/workspace/github-merge-juju/tmp.f4uCbWbBZu/RELEASE/src/runtime/trace (from $GOPATH)
[03:42] <davecheney> shake's fist at Go 1.2
[03:43]  * davecheney deletes things til go 1.2 stops complaining
[04:03] <mup> Bug #1540316 changed: provider/maas: bridgescript should support vlans <maas-provider> <juju-core:New> <https://launchpad.net/bugs/1540316>
[04:06] <mup> Bug #1540316 opened: provider/maas: bridgescript should support vlans <maas-provider> <juju-core:New> <https://launchpad.net/bugs/1540316>
[04:15] <mup> Bug #1540316 changed: provider/maas: bridgescript should support vlans <maas-provider> <juju-core:New> <https://launchpad.net/bugs/1540316>
[04:25] <axw> wallyworld: not quite as big as your diffs, but sorry all the same: http://reviews.vapour.ws/r/3698/diff/#
[04:26] <wallyworld> revenge is sweet
[04:26] <axw> on a positive note, net reduction of ~1600 lines
[04:49] <wallyworld> axw: reviewed, i love seeing code deleted
[04:49] <axw> wallyworld: thanks
[04:53] <axw> wallyworld: there's a card for creating the second model already, is a TODO necessary?
[04:53] <wallyworld> nah
[05:26] <davecheney> thumper, each client of a 1.25 api server consumes 50 goroutines
[06:17] <axw> wallyworld: how do you feel about this? https://github.com/juju/juju/compare/cloud-credentials...axw:cloud-credentials-detect-regions
[06:23] <anastasiamac> axw: love the name! detector :D
[06:24] <wallyworld> axw: looking
[06:29] <wallyworld> axw: it does give a way to avoid having a personal clouds file for openstack, if standard env vars are set via sourcing a credentials file or whatever
[06:29] <wallyworld> i think it makes sense
[06:29] <wallyworld> and we can use an lxd env var for the lxd host
[06:30] <axw> wallyworld: might not even need to, you could list the remotes
[06:30] <axw> wallyworld: e.g. "lxc remote list"
[06:30] <axw> wallyworld: and report each of those as a region
[06:30] <wallyworld> true
[06:31] <axw> wallyworld: I'll tidy this up and propose then. it's a bit less hacky than what was there, and supports openstack. we can revisit if there's dissent
[06:33] <wallyworld> yup
[09:09] <voidspace> dimitern: thanks for the review, I replied to all your comments.
[09:10] <voidspace> dimitern: is your WIP branch ready yet?
[09:11] <dimitern> voidspace, it is ready - the ci run last night revealed the main issue, which I'm fixing now: don't assume bindings always exist
[09:12] <dimitern> voidspace, so I'll be pushing a few more commits on top to fix that and re-enable the tests I disabled
[09:12] <voidspace> dimitern: cool
[09:28] <dimitern> voidspace, responded to your replies
[09:33] <voidspace> dimitern: I think you're actually wrong about the test channel - the test really is the owner as it closes the channel.
[09:33] <voidspace> dimitern: and the "code path" is still the same.
[09:33] <voidspace> dimitern: the other two issues - ok.
[09:35] <dimitern> voidspace, I don't mind that much if you leave the chan creation outside of the patched func
[10:02] <frobware> dimitern, standup
[10:08] <voidspace> frobware: dimitern: dooferlad: PR for merge of latest master changes back to maas-spaces. http://reviews.vapour.ws/r/3703/
[10:12] <dimitern> voidspace, LGTM - you'll likely manage to land this before my branch which also includes it, so there shouldn't be a conflict
[10:13] <mup> Bug #1540832 opened: Hard wired bridge prevents the use of the fan overlay network <juju-core:New> <https://launchpad.net/bugs/1540832>
[10:16] <mup> Bug #1540832 changed: Hard wired bridge prevents the use of the fan overlay network <juju-core:New> <https://launchpad.net/bugs/1540832>
[10:19] <mup> Bug #1540832 opened: Hard wired bridge prevents the use of the fan overlay network <juju-core:New> <https://launchpad.net/bugs/1540832>
[10:51] <frobware> dimitern, dooferlad, voidspace, jam: the trusty/series issue we talked about in the standup is being tracked here atm: https://bugs.launchpad.net/juju-core/+bug/1540771
[10:51] <mup> Bug #1540771: Bootstrap fails with trusty is not a valid distro_series <bootstrap> <juju-core:Invalid> <juju-core maas-spaces:Triaged> <https://launchpad.net/bugs/1540771>
[10:53] <frobware> mgz, looking for help with bug 1540771. dimitern plans to update his branch again (RSN) and we'll want another CI run but little point if we keep running into said bug.
[10:53] <mup> Bug #1540771: Bootstrap fails with trusty is not a valid distro_series <bootstrap> <juju-core:Invalid> <juju-core maas-spaces:Triaged> <https://launchpad.net/bugs/1540771>
[11:22] <dooferlad> frobware/dimitern/voidspace: Updated bind syntax: http://reviews.vapour.ws/r/3569/diff
[11:23] <dimitern> dooferlad, cheers, looking
[11:34] <dimitern> dooferlad, reviewed
[12:07] <dooferlad> dimitern: http://reviews.vapour.ws/r/3569 addressed those issues.
[12:28] <dimitern> dooferlad, thanks! let's get it in then I guess
[12:38] <mup> Bug #1540900 opened: juju deploy ignores model default-series <juju-core:New> <https://launchpad.net/bugs/1540900>
[12:46] <jam> fwereade_: ping
[12:47] <mup> Bug #1540900 changed: juju deploy ignores model default-series <juju-core:New> <https://launchpad.net/bugs/1540900>
[12:47] <mfoord> frobware: what's the release notes link again please
[12:48] <mfoord> frobware: never mind, found it
[12:48] <frobware> mfoord, thought so as you show up as already viewing. :)
[12:53] <mfoord> frobware: heh
[12:56] <mup> Bug #1540900 opened: juju deploy ignores model default-series <juju-core:New> <https://launchpad.net/bugs/1540900>
[12:56] <jam> fwereade_: I had a question about "connects", and another one about some lxd configuration stuff
[13:17] <fwereade_> jam, heyhey
[14:01] <voidspace> cherylj:  dimitern:  frobware: alexisb: given that 2.0 is dropping maas 1.8 support we should probably not mention improved support for maas 1.8 in the release notes (there's a maas 1.8 compatibility section)
[14:01] <voidspace> bug 1534636
[14:01] <mup> Bug #1534636: Destroying a hosted model in the local provider leaves the controller unusable <juju-release-support> <juju-core:Triaged> <https://launchpad.net/bugs/1534636>
[14:01] <frobware> jam: saw your doc, but punting until I get the maas-spaces unit tests to work on ppc64
[14:02] <voidspace> cherylj:  dimitern:  frobware: alexisb: we can probably also drop the mention of bug 1534636 as a known issue, as the local provider won't
[14:02] <voidspace> *won't be there in 2.0
[14:02]  * voidspace lunches
[14:02]  * frobware follows suit
[14:06] <dimitern> cherylj, frobware, alexisb, voidspace, I think that section was copied from 1.25 rel. notes, so we should indeed drop it for the 2.0 notes
[14:16] <jam> fwereade_: hey, still around?
[14:36] <perrito666> bbl
[14:41] <fwereade_> jam, ha, yes, but apparently notification-blind
[14:42] <mattyw> jam, any reason why we shouldn't do $$merge$$ on this https://github.com/juju/juju/pull/4131 ?
[14:44] <cherylj> mattyw: yes, we are trying to get some branches landed and we'd rather not have master be a moving target
[14:44] <mattyw> cherylj, ok cool thanks
[14:45] <cherylj> frobware: I see now that maas-spaces has some new commits.  What's the expectation now for testing?  are we still testing dimitern's branch?
[14:47] <mattyw> cherylj, ok - judging by the comment lxd provider is broken in xenail so it probably needs to land before the release - but I don't really know
[14:47] <mattyw> cherylj, I'm not involved - I'm just an interested party
[14:48] <cherylj> mattyw: we can look at getting it into alpha2, but really, if it misses, alpha3 is next week
[14:48] <mattyw> cherylj, ack
[14:59] <frobware> cherylj, yes, new commits for blocking API and bootstrap whilst discovery taking place (this is the one we talked about last night). bind syntax change for '@' -> '=' which came out of CT. and merge current master into maas-spaces.
[14:59] <frobware> cherylj, dimitern is updating and fixing tests based on the CI run.
[14:59] <cherylj> frobware: is dimitern's branch up to date with maas-spaces again?
[14:59] <frobware> cherylj, dimitern: do you plan to rebase maas-spaces onto your branch?
[15:00] <cherylj> otherwise we need to get a bless on dimitern's, then merge into maas-spaces, then get a bless on maas-spaces before it can all land in master
[15:00] <frobware> cherylj, ack.
[15:00] <frobware> cherylj, I would advocate that dimiter rebases so we only do test once
[15:01] <cherylj> frobware: agreed
[15:01] <cherylj> and don't forget to pull in master too.  There were some changes that came in
[15:01] <frobware> cherylj, we did yesterday - need to check if we're talking about the same change.
[15:01] <cherylj> frobware: probably same one.  the pprof thing
[15:02] <frobware> cherylj, yep
[15:02] <frobware> cherylj, 3 things to fix in dimiter's branch: CI test failures surrounding bindings, skipped unit tests (though for expediency we could skip these), and ppc64 unit test failures.
[15:02] <cherylj> frobware: wallyworld has a PR up for a different bug that's only been seen on his branch (although the underlying problem exists on master too).  I think it should go into his branch rather than master so we can demonstrate in CI that it fixes the problem
[15:03] <cherylj> frobware: what's the confidence level in getting a bless on dimitern's branch today
[15:05] <frobware> cherylj, ppc64 might still fail. looking at that now. need to hear from dimiter about progress on the other problems. also bug 1540771 might cause a cursed build again.
[15:05] <mup> Bug #1540771: Bootstrap fails with trusty is not a valid distro_series <bootstrap> <juju-core:Invalid> <juju-core maas-spaces:Triaged> <https://launchpad.net/bugs/1540771>
[15:06] <cherylj> frobware: is that bug a problem with the MAAS setup?  or a problem on the branch?
[15:07] <frobware> cherylj, I would say MAAS setup and/or CI setup.
[15:07] <cherylj> frobware: is there someone who can work with jog_ to track it down so we don't hit it again?
[15:09] <frobware> cherylj, put me down, though I have a hard commitment 7:30pm.
[15:11] <cherylj> frobware: ok, jog_ should be in before then
[15:11] <frobware> cherylj, I'm not entirely sure how quick a CI run can be but I would advocate we have a stripped down run that initially only runs the failures; we need to iterate faster
[15:12] <cherylj> frobware: yes, but your changes could cause some of the previously passing tests to fail, so we need to get a complete run before a merge.  We could see about doing some initial tests for verification before a complete run
[15:12] <cherylj> sinzui: is there a way we could just run selected tests for maas-spaces?
[15:12] <cherylj> mgz: ^^
[15:12] <frobware> cherylj, agreed.
[15:13] <frobware> cherylj, I just don't want to wait $N hours to find out we haven't fixed the existing failures
[15:14] <cherylj> frobware: yeah, I understand
[15:18] <sinzui> cherylj: we can re-run selected tests for previously tested revisions. We cna do this beause we saved  the built packages and streams. We cannot run tests with a branch.
[15:21] <frobware> cherylj, do you know if we have access to ppc64?
[15:22] <frobware> I'm futzing trying to fix this unit test failure
[15:22] <frobware> I have a qemu ppc64 running but it's not terribly efficient or productive.
[15:22] <frobware> actually, I cannot build juju atm (on ppc64)
[15:24] <cherylj> mgz, sinzui, is it possible to get frobware access to the CI ppc machines?
[15:26] <sinzui> cherylj: yes, though I am informed that ports.ubuntu.com is down and that limits what we can do. No installs
[15:26] <cherylj> sinzui: should be okay, it's just a unit test run
[15:26] <frobware> sinzui, cherylj: ah, that explains some of my problems over the last 20 mins.
[15:26] <cherylj> d'oh
[15:34] <cherylj> frobware, dimitern, I've copied over the charms that CI uses for the basic deploy tests here:  https://private-fileshare.canonical.com/~cherylj/dummy-charms/
[15:34] <cherylj> there's also a txt file with the steps used to deploy
[15:35] <cherylj> you can start with testing on AWS, since that's failing on the maas-spaces-controller-space-config
[15:37] <frobware> dooferlad, if you're between tasks please could you help out on the test failures ^^
[15:37] <dooferlad> frobware: I am not quite, but will be soon.
[15:40] <natefinch> ericsnow: it occurs to me that we need to have the resource download code on the server regardless, to support the GUI
[15:41] <ericsnow> natefinch: I wasn't aware of any GUI-related requirements
[15:42] <natefinch> ericsnow: I think rick_h__ would probably be upset if we couldn't deploy charms from the gui that used resources in the charmstore
[15:42] <ericsnow> natefinch: regardless, you make a good point about what the GUI might need
[15:42] <natefinch> ericsnow: but you're right that there was nothing in the spec about it
[15:42] <cherylj> fwereade_: would you be able to review https://github.com/juju/juju/pull/4266 ?  It's related to that bug I talked to you about yesterday
[15:42] <ericsnow> natefinch: I can follow up with the GUI team
[15:45] <rick_h__> natefinch: can you email the context there?
[15:47] <natefinch> rick_h__: sure
[15:49] <ericsnow> rick_h__, natefinch: I just send an email
[15:49] <rick_h__> natefinch: ty on my phobe aylt the conference and want to better follow what's up
[15:51] <fwereade_> cherylj, alexisb: ack
[15:53] <ericsnow> natefinch: let's get back together some time after lunch to put together the demo for last iteration
[15:53] <natefinch> ericsnow: ok
[16:13] <jog> hi frobware, I'm here if you have questions about bug 1540771
[16:13] <mup> Bug #1540771: Bootstrap fails with trusty is not a valid distro_series <bootstrap> <juju-core:Invalid> <juju-core maas-spaces:Triaged> <https://launchpad.net/bugs/1540771>
[16:15] <frobware> jog, immediate question is if we run again will this just repeat. is this at related to not running against MAAS 1.7 or 1.8?
[16:18] <jog> frobware, it failed several time in a row in the same way. Master had run before maas-spaces and passed. The bug is open for failures against MAAS 1.9
[16:19] <frobware> jog, but new against 1.9?
[16:19] <jog> frobware, not sure what you mean?
[16:22] <frobware> jog, trying to understand whether it is our branch that causes the failure or a separate 1.9 issue
[16:24] <jog> well I just reran the last revision of master (1cb8f03) and don't see the failure there. I'm running the maas-spaces revision that failed again now, just to be sure there was no other issue.
[16:27] <frobware> dimitern, ^^
[16:28] <frobware> jog, thx - will keep an eye out for the result.
[16:35] <frobware> jog, is your "reran" http://reports.vapour.ws/releases/3564
[16:35] <frobware> jog, because that show as cursed
[16:36] <frobware> jog, ah, but only for ppc64.
[17:01] <natefinch> man, the function that actually does charm deployments from the client is a hairy mess
[17:02] <natefinch> 100 lines of if statements
[17:03] <perrito666> how sad
[17:04] <natefinch> and weird implicit meanings to error values... good lord
[17:07] <natefinch> perrito666: https://github.com/juju/juju/blob/master/cmd/juju/commands/deploy.go#L249
[17:08] <perrito666> deploy charm Or bundle, just in case
[17:08] <perrito666> is there a reason why that is not the at least 3 methods it should be?
[17:09] <natefinch> perrito666: the problem is that our deploy command does way too much and has way too much encoded into the string we pass it
[17:09] <perrito666> "we might have been given a bundle" <-- that is one.  " if not a bundle then maybe a local charm" <- there is another,
[17:10] <natefinch> the fact that this code is a nightmare is just an indication that the UX is a nightmare...
[17:10] <natefinch> I mean, the code could be better even given the bad UX
[17:10] <perrito666> that is not true, code can be bad and ux be decent
[17:11] <perrito666> I have  glanced at that function and already know it can be split
[17:11] <perrito666> I do have the "fresh pair of eyes" advantage
[17:11] <natefinch> yeah, it absolutely should be refactored
[17:11] <perrito666> but cmon, a bit of good will might make things better
[17:11] <natefinch> I think someone added bundles and just didn't want to refactor what was there
[17:12] <perrito666> well mcdonalds lunch is not the best alternative to stay awake after lunch
[17:12] <natefinch> heh
[17:21] <perrito666> bbl
[17:24] <natefinch> oh how nice, we're throwing away an error and assuming we know what was in it
[17:25] <natefinch> oh hey, someone fixed it on master... ok, I gotta rebase.
[18:08] <voidspace> dimitern: we have 19 code branches checking for the AddressAllocation feature flag
[18:16] <dimitern> voidspace, so next step is to prepare a PR that drops them I guess
[18:24] <voidspace> dimitern: did we ever get devices by default on master?
[18:24] <voidspace> dimitern: it looks to me, from skimming the code, that if we lose AddressAllocation we lose containers as devices too
[18:25] <voidspace> dimitern: and we go back to leaking DHCP leases
[18:39] <perrito666> bq
[18:53] <dimitern> voidspace, that's ok - we'll redo it properly anyway
[19:23] <natefinch> gah, why do we have a client api function that no one calls? (ServiceDeployWithNetworks)
[19:25] <natefinch> .....maybe we keep it so the tests can test the server's backwards compatibility
[19:26] <natefinch> hmm, in which case it should be in test code only.
[19:27] <mup> Bug #1540469 changed: [ARM64][LXD Provider][2.0-alpha1-0ubuntu1~16.04.1~juju1] juju run command ERROR fork/exec /usr/bin/ssh: cannot allocate memory <run> <juju-core:New> <https://launchpad.net/bugs/1540469>
[19:30] <mup> Bug #1540469 opened: [ARM64][LXD Provider][2.0-alpha1-0ubuntu1~16.04.1~juju1] juju run command ERROR fork/exec /usr/bin/ssh: cannot allocate memory <run> <juju-core:New> <https://launchpad.net/bugs/1540469>
[19:32] <perrito666> natefinch: are you sure no one calls it?
[19:32] <natefinch> perrito666: grep says it's only called in tests
[19:32] <perrito666> I do recall that there is a cascade of calls for service deploy
[19:32] <perrito666> ServiceDeploy -> serviceDeployWithX -> ServiceDeployWithY and so on
[19:33] <perrito666> natefinch: take a look a few versions back, perhaps its legacy and asking to go
[19:34] <natefinch> perrito666: yeah, almost certainly... like I said, my guess is that it needs to stick around for testing that we keep backwards compatibility with old clients... but that means it should be moved to test code, so it's more obviously something you should let rot in a corner
[19:34] <perrito666> actually, if you are working in 2, that is a death sentence
[19:36] <mup> Bug #1540469 changed: [ARM64][LXD Provider][2.0-alpha1-0ubuntu1~16.04.1~juju1] juju run command ERROR fork/exec /usr/bin/ssh: cannot allocate memory <run> <juju-core:New> <https://launchpad.net/bugs/1540469>
[19:38] <natefinch> perrito666: *shrug* I'll file a bug
[19:39] <mup> Bug #1540469 opened: [ARM64][LXD Provider][2.0-alpha1-0ubuntu1~16.04.1~juju1] juju run command ERROR fork/exec /usr/bin/ssh: cannot allocate memory <run> <juju-core:New> <https://launchpad.net/bugs/1540469>
[19:42] <mup> Bug #1540469 changed: [ARM64][LXD Provider][2.0-alpha1-0ubuntu1~16.04.1~juju1] juju run command ERROR fork/exec /usr/bin/ssh: cannot allocate memory <run> <juju-core:New> <https://launchpad.net/bugs/1540469>
[20:03] <natefinch> dammit... something is throttleing the hell out of my laptop lately
[20:03] <perrito666> natefinch: use htop?
[20:04] <perrito666> aghh, sms spam, just what I needed
[20:05] <natefinch> perrito666: htop is very pretty and I have no idea what it means
[20:05] <perrito666> natefinch: use the man page
[20:06] <perrito666> if the upper graphs for microprocessor are full (or the ram one) something is behaving wrongly, you can use f6 iirc to sort things by cpu or ram
[20:06] <perrito666> and that would put the culprit at the top
[20:09] <natefinch> perrito666: I'm running tests, and expect my processors to all be pegged, but they're all at like 50%, and my tests are taking a lot longer than usual to run
[20:10] <perrito666> natefinch: try iotop then
[20:10] <perrito666> perhaps something is hammering your hd
[20:13] <natefinch> hmm disk read is always 0, I presume that's a bug, or my computer would not be working ;)
[20:28] <natefinch> that weird feeling when you change the signature of like 3 very important functions.... and no tests fail
[20:28] <natefinch> ...I'm sure it's fine
[20:29] <perrito666> natefinch: http://www.quickmeme.com/img/a7/a7eb19ae524e1d066fae16e5e7c0438c86fa321468cd3e3d0764731cf86f869c.jpg
[20:29] <natefinch> lol indeed
[21:04] <davechen1y> no menn0 today ?
[21:04] <davechen1y> paging the on call reviewer: http://reviews.vapour.ws/r/3700/
[21:04] <davechen1y> to the OR, STAT!
[21:05] <perrito666> that is me
[21:05]  * perrito666 reviews
[21:05] <perrito666> stat?
[21:06] <natefinch> perrito666: means "right now"
[21:06] <natefinch> perrito666: I believe it was backronymed to Sooner Than Already There
[21:07]  * natefinch makes perrito666 google backronym instead of stat
[21:07] <perrito666> natefinch: its ok, for me davechen1y 's now is 11 hours away so technically I can pull it
[21:09] <natefinch> perrito666: https://www.youtube.com/watch?v=gNIwlRClHsQ
[21:13] <natefinch> ericsnow: I gotta run a little early today (will be back later as usual).  Want to talk demo?
[21:14] <ericsnow> natefinch: sure
[21:14] <ericsnow> natefinch: moonstone
[21:18] <perrito666> davechen1y: there you got a bunch of fixmes :p and all more than 10 hours before your asked time
[21:18] <menn0> waigani: ship it on the auth worker PR
[21:20] <waigani> menn0: thanks
[21:43]  * perrito666 makes coffee before a long long review
[21:58] <natefinch> bbl
[22:21] <perrito666> I wish we had un-shipit as an option
[22:53] <menn0> waigani: deployer review done
[23:06] <menn0> wallyworld: http://reviews.vapour.ws/r/3711/ doesn't need a review right?
[23:07] <wallyworld> menn0: nope, is a straight merge of a feature branch
[23:07] <wallyworld> a huge one at that
[23:07] <menn0> wallyworld: I noticed so I'm glad to hear I don't need to review it :)
[23:08] <wallyworld> all the terminology changes etc
[23:08] <wallyworld> as per your earlier email to dev list
[23:08] <wallyworld> model model model
[23:12] <wallyworld> cherylj: i wonder if the add-machine "regression" is just a timebomb in 1.25 say, waiting to show up like the leadership issue did, and we just haven't seen it yet
[23:13] <wallyworld> you'd think it would show up in more places
[23:13] <perrito666> menn0: tx for the rev
[23:18] <rick_h__> just dropping as an FYI: https://twitter.com/mitechie/status/694506568000344064
[23:19] <perrito666> neat
[23:20] <rick_h__> yea, really good attendance here at the summit
[23:23]  * perrito666 wanted to go
[23:24] <rick_h__> we'll have to hit up the next one. We had a couple of core folks here
[23:29] <davechen1y> cherylj: when will the next 1.25 build come out ?
[23:30] <davechen1y> ie, if I want to get my profiling stuff into a 1.25 build
[23:30] <davechen1y> what deadline should I focus on ?
[23:41] <cherylj> davechen1y: I'm targeting late next week
[23:41] <cherylj> for 1.25.4
[23:42] <cherylj> hooray!  api-command-rename has LANDED!
[23:43]  * rick_h__ does a giant happy dance
[23:43] <cherylj> master will stay blocked until we get a bless
[23:43] <cherylj> then we shall open up the flood gates


[00:05] <bjf> cyphermox, it's sooo much nicer to make those kinds of requests to the mailing list
[00:06] <cyphermox> sure
[00:08] <bjf> cyphermox, just more likely for the right person to see it and less likely that it gets missed or forgotten
[00:08] <cyphermox> bjf: you're totally right
[00:08] <cyphermox> I'll send it shortly :)
[00:08] <bjf> thanks
[00:14] <cyphermox> bjf: sent it, sorry; I was multitasking -- it should have been my first action :)
[07:18] <infinity> zequence: World respun, again.  If you want to do a few quick rebases. :/
[07:19] <infinity> zequence: bug #1188461 bug #1188495 and bug #1188466
[07:19] <ubot2`> Launchpad bug 1188461 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1188461
[07:19] <ubot2`> Launchpad bug 1188495 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1188495
[07:19] <ubot2`> Launchpad bug 1188466 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1188466
[08:14] <ppisati> did we respin P?
[08:14] <infinity> ppisati: P, Q, and R, even.
[08:15] <ppisati> infinity: i mean tonight
[08:15] <infinity> ppisati: iwlwifi-specific, so it doesn't really affect ARM, but since your branch hasn't been uploaded yet anyway, may as well rebase.
[08:15] <infinity> ppisati: Yeah, we respun all three today.
[08:16] <infinity> ppisati: bug #1188464 and bug #1188492
[08:16] <ubot2`> Launchpad bug 1188464 in Kernel SRU Workflow "linux-ti-omap4: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1188464
[08:16] <ubot2`> Launchpad bug 1188492 in Kernel SRU Workflow "linux-ti-omap4: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1188492
[08:17] <ppisati> i see onlyne one respin to be done:
[08:17] <ppisati> http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html
[08:18] <infinity> ppisati: The quantal bug was just made, the workflow report is behind.  Hence my linking it for you. :)
[09:45] <ppisati> infinity: can you publish to the ckt ppa the unpubblished Q/omap4 kernel? i need
[09:46] <ppisati> infinity: it for kteam-tools ABI script
[11:40] <apw> cyphermox, yo ... CONFIG_BT_HCISMD do you want =y or =m there?
[11:40] <apw> cyphermox, also, this option does exist for mako, but never did for maguro
[11:42] <apw> cyphermox, ok replied in email
[11:54] <ogra> root@ubuntu-phablet:/# uname -r
[11:54] <ogra> 3.0.0-1-maguro
[11:54] <ogra> root@ubuntu-phablet:/# zgrep DEVTMPFS /proc/config.gz
[11:54] <ogra> CONFIG_DEVTMPFS=y
[11:54] <ogra> # CONFIG_DEVTMPFS_MOUNT is not set
[11:54] <ogra> hmpf
[11:54] <ogra> could we fix that for all ubuntu touch kernels ?
[11:54] <apw> ogra, yep
[11:54] <ogra> thx
[11:54] <apw> ogra, though our standard tooling does cope with it normally
[11:55] <ogra> i might also have an additional grouper change
[11:55] <ogra> yeah, i know but it slows down booting if the script has to kick in
[11:55] <ogra> (minor but it does)
[11:55] <apw> yep
[11:55]  * ogra sighs about grouper ...
[11:55] <ogra> while it is so easy for desktops it is a pain with android ...
[11:59] <apw> ogra, ok those have already been fixed across the board in rtg's next kernels
[12:00] <ogra> awesome !
[12:00] <ogra> rtg_, rocks :)
[12:00] <rtg_> ogra, um, what did I do ?
[12:00] <ogra> #
[12:01] <ogra> CONFIG_DEVTMPFS_MOUNT
[12:01] <ogra> fixing that
[12:01] <ogra> (on the touch kernels)
[12:01] <rtg_> ogra, now I'm struggling with perf. kind of a PITA to get built.
[12:02] <ogra> well, i'm fighting with a non booting grouper over here ... it is the only arch having massive probs with the container flip
[12:08]  * henrix -> lunch
[12:19] <rtg_> apw, linux_3.10.0-0.2_source.changes rejected, PPA exceeded its size limit (16472.00 of 16384.00 MiB).
[12:25] <brendand> anyone have details for this respin: https://bugs.launchpad.net/kernel-sru-workflow/+bug/1186271
[12:25] <ubot2`> Ubuntu bug 1187926 in Kernel SRU Workflow verification-testing "duplicate for #1186271 linux: 3.5.0-34.55 -proposed tracker" [Medium,In progress]
[12:25] <rtg_> apw, nm. I see you uploaded to a different PPA
[12:25] <rtg_> brendand, you'll have to wait for sconklin or infinity
[12:28] <henrix> brendand: there was a regression in iwlwifi driver
[12:29] <henrix> brendand: this bug #1186932
[12:29] <ubot2`> Launchpad bug 1186932 in linux (Ubuntu) "Regression: kernel 3.8.0-24 breaks WPA enterprise auth [iwlwifi]" [High,Confirmed] https://launchpad.net/bugs/1186932
[12:29] <apw> rtg_, yeah i am waiting for the PPA to register that i have deleted everything in it
[12:29] <apw> rtg_, then i am going to pocket copy it out of the /ppa PPA when it is built
[12:29] <brendand> henrix, i wonder can we have a convention to post details of the respin on the tracking bug, to reduce the level of mystery :/
[12:30] <henrix> brendand: :) that would probably make sense
[12:30] <henrix> brendand: i believe bjf was discussing something along those lines yesterday, but not sure about the details
[13:08] <apw> smb, you have a lucid box i think, could you test something for me
[13:08] <apw> smb, specifically can you see if the following oopses it for me
[13:08] <apw>   $ cd /sys/kernel/debug/tracing
[13:08] <apw>   $ echo 1234 | sudo tee -a set_ftrace_pid
[13:08] <smb> apw, If it does not have to be real hw...
[13:08] <apw> oh good point i have VMs
[13:09]  * apw goes boot op something
[13:09] <apw> p
[13:09] <apw> up
[13:09] <apw> erp
[13:09] <smb> apw, Yeah, I would not be sure whether I still got something bare-metal on L
[13:10] <apw> smb, no i was thinking of your precise machine ... getting my OLD lts' mixed up
[13:10] <smb> apw, Oh yeah, I know _that_ feeling. :)
[13:10] <apw> i suspect i am going senile
[13:11] <smb> And then there is the whole 2.6.32 vs 3.2 confusion
[13:11] <apw> heh ... i only have a server install for L thats how old it feels
[13:11] <apw> must get those isos down and build some L desktops ...
[13:11] <smb> good point...
[13:12] <smb> I think I don't have one of those either
[13:21]  * apw installs both anyhow
[13:52] <sconklin> brendand: was that enough of an answer that you got earlier?
[13:53] <brendand> sconklin, yes
[14:12] <smb> apw, I seem not to get an oops
[14:12] <apw> smb, great, me either, that confirms my analysis that that release is not affected
[14:17] <rtg_> apw, I'll pick up mako CONFIG_BT_HCISMD when I enable perf.
[14:21] <apw> rtg_, ack
[14:44] <arges> rtg_: hi
[14:45] <rtg_> arges, yo
[14:45] <arges> rtg_: looking at your iptables patch here: http://git.netfilter.org/iptables/commit/?id=79ddbf202a06e6f018e087a328c2ca91e65a8463
[14:45] <rtg_> arges, don't fear the reaper
[14:45] <arges> i'm trying to merge 1.4.18, and i noticed that some of the stuff in your debian patch didn't make it into that commit
[14:45] <arges> heh
[14:46] <rtg_> arges, really ? like what ?
[14:46] <arges> rtg_: these were the changes that were in the 9002- patch but not in that commit: http://pastebin.ubuntu.com/5742113/
[14:46] <arges> Not sure if they are necessary, or can be dropped. or if there is a good way to test (try --reap with --seconds etc)
[14:47] <rtg_> arges, that one seems kind of important IIRC
[14:47] <rtg_> arges, the reaper needs a periodic cycle time
[14:48] <arges> rtg_: ok well those changs aren't in the lastest iptables git. so maybe it needs to be resubmitted
[14:49] <rtg_> arges, feel free to hassle him
[14:49] <arges> ok : )
[14:49] <rtg_> there doesn't seem to be any obvious reason why that bit would not have been included
[16:37]  * apw revs up to calling it a day
[17:29]  * rtg_ -> lunch
[17:55] <infinity> zequence: You around?
[17:57] <infinity> zequence: The current respins of P/Q/R are fairly important for x86 users (so, lowlatency counts there), as they fix a nasty regression in iwl wifi.
[17:57] <infinity> zequence: Should be a dirt simple rebase, it's a 1-line fix.
[18:05] <zequence> infinity: alright. I'll get right to it
[18:07] <infinity> zequence: Thanks.  You're a champion.
[18:10] <zequence> I will be if my bits stay in order :P
[18:10] <infinity> *cough*
[18:10] <infinity> debdiff before you upload. :)
[18:10] <infinity> Ideally against the one from -proposed, not against what's on your hard drive. :P
[18:11] <zequence> infinity: Oh, so that will error if there's an error?
[18:11] <infinity> zequence: No, but it'll tell you if some random file you didn't mean to change got changed.
[18:11] <infinity> debdiff old.dsc new.dsc > foo.diff && lsdiff foo.diff (or just read the diff)
[18:13] <zequence> infinity: ok, thanks
[19:17] <ppisati> "omap4 3.2.0-1433.43 failed to build"
[19:17] <ppisati> WTF?
[19:18] <bjf> looking
[19:19] <bjf> still showing "currently building" for me
[19:20] <ppisati> got an email sayign "failed to build blablabla"
[20:40]  * rtg_ -> EOW
[22:36] <zequence> infinity: I can't get the packages built today. Something is not right. I really need to crash, so it'll have to wait until tomorrow


[11:03] <Guest68326> Ok  Grumpy is here :)
[11:06] <zequence> Guest92208: Welcome :)
[11:06] <Guest92208> TY  to bad Grumpy is taken lol
[11:07] <Guest92208> any idea how to find out what nick,s are in use ?
[11:08] <zequence> You mean like, get a list of all nicks either registered or in use?
[11:08] <Guest92208> do read howto,s but mmm  not yet found
[11:08] <Guest92208> registrered i gues
[11:08] <zequence> I would guess there are quite a lot of them, but if you figure out something fairly unusual, I'm sure it'll work
[11:09] <Guest92208> lol   i see
[11:10] <Guest92208> how can i help ?
[11:17] <zequence> Guest92208: Just follow the mail list and this channel. Read more at the link I gave you, to get a better idea. Then, jump in whenever you find you could do something
[11:18] <zequence> Guest92208: Here's a very incomplete documentation about the development process https://wiki.ubuntu.com/UbuntuStudio/DevelopmentCycle
[11:19] <zequence> Probably what you want to start with is testing. None going on right now, but we need people to write tests in the coming cycle(s)
[11:19] <zequence> I just put out a mail about us needing to organize that in the coming weeks
[11:21] <Guest92208> no mail yet ,feels like i stand in a forest and see no tree
[11:22] <Guest92208> what is wisdom to set up in virtualbox a studio 64 or 32 bits ?  i use 64
[11:23] <zequence> Guest92208: Both may be required
[11:23] <zequence> We always test both anyway
[11:24] <zequence> Guest92208: See previous mails here https://lists.ubuntu.com/archives/ubuntu-studio-devel/2014-May/thread.html
[11:24] <Guest92208> will do that
[11:24] <zequence> Guest92208: What we test is the current development release, which is 14.10
[11:24] <zequence> You can find the current ISO here http://cdimage.ubuntu.com/ubuntustudio/dvd/current/
[11:25] <Guest92208> downloading  , wonder it say daily build do you need to reinstall every week then ?
[11:31] <zequence> Guest92208: No, you just need to update the system if you want more recent versions of packages
[11:33] <zequence> Guest92208: Keep the ISO. If you decide to download again, use zsync. It will only download the changes in the ISO, not the whole ISO itself
[11:34] <zequence> With a terminal, in the path where the ISO is, for the 64bit version, you would do: cdimage.ubuntu.com/ubuntustudio/dvd/current/utopic-dvd-amd64.iso.zsync
[11:34] <zequence> sorry: zsync cdimage.ubuntu.com/ubuntustudio/dvd/current/utopic-dvd-amd64.iso.zsync
[11:34] <zequence> Nah..
[11:34] <Guest92208> ok  got me some work
[11:34] <zequence> zsync http://cdimage.ubuntu.com/ubuntustudio/dvd/current/utopic-dvd-amd64.iso.zsync
[11:34] <zequence> Third time the charm
[12:21] <Guest92208> zequence  how much memory for the virtual machines   1G or 1.5
[12:50] <zequence> Guest92208: Depends on how much RAM you have on your machine. I would go with 2GB if you can spare it
[13:12] <Guest92208> older system   -Computer-
[13:12] <Guest92208> Processor		: 2x Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz
[13:13] <Guest92208> Memory		: 3721MB (1034MB used)  Resolution		: 1280x1024 pixels
[13:13] <Guest92208> Audio Adapter		: Audigy - SB Audigy 1 [SB0090]           Audio Adapter		: HDA-Intel - HDA Intel
[13:21] <zequence> 1GB is enough in your case
[13:25] <Guest92208> will set them up and see how things work out
[13:30] <Guest92208> i hate redirects  yuck i  go to : http://www.ubuntu.com/support/community/mailinglists/etiquette  " and send to "http://www.ubuntu.com/partners"
[13:31] <Guest92208> link is on " https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel "
[13:33] <zequence> Guest92208: Wow. Didn't know about that. Let me add a rt ticket for that.
[13:34] <zequence> rt tickets are for the Canonical sysadmins who administer mail lists, and also our website (the content is of course managed by us)
[13:34] <Guest92208> :) i done something lol
[13:35] <zequence> Hmm, maybe it's our fault. Let me see
[13:35] <Guest92208> yes see you are the dev manager  got the mailing list  request ?
[13:36] <dutch_Grumpy> lol
[13:39] <zequence> dutch_Grumpy: Changed it
[13:40] <dutch_Grumpy> OK  installing the machines now
[16:42] <dutch_Grumpy> Ok  tomorrow more :)


[00:00] <Riddell> shtylman: artwork is kwwii's domain
[00:00] <Riddell> I don't know about openoffice, wasn't it waiting on an upstream release?
[00:01] <shtylman> hmm..might be...
[00:01] <shtylman> well...the stuff is there...so whenever that happens we will have the free space from kde3 libs
[00:04] <Riddell> we don't have kde 3 libs currently
[00:04] <Riddell> we have an unthemed openoffice
[00:04] <shtylman> oh...goodie :)
[00:04] <shtylman> no wonder it looks like death
[00:04] <shtylman> I was wondering about that...
[00:05] <Riddell> shtylman: do you know what upstream release of openoffice we've waiting for?
[00:06] <shtylman> Riddell: I think 3.2 ?
[00:06] <shtylman> or one of the 3.1 lines
[00:06] <shtylman> 3.1 actually
[00:07] <shtylman> yea...I 3.1 if I remember right from a conversation I had with ccheney
[00:13] <claydoh> ScottK: re: release notes they were mostly done before I got there, I did add a few images, etc
[00:41] <seele> shtylman: if you are looking for something to do, printing needs love
[00:42] <shtylman> seele: what type of love does it need?? also seele...take a look at: http://shtylman.com/stuff/kubuntu_installer/installer_dialog.png
[00:43] <shtylman> I want to change the installer popup dialogs to that...
[00:43] <shtylman> (ignore the other things we talked about) that have been fixed in the real version
[01:06] <shtylman> seele: ??
[01:08] <Riddell> shtylman: the system-config-printer-tool needs to get feature parity with the gnome one, and have usability love applied
[01:08] <Riddell> it's all python
[01:08] <shtylman> Riddell: alrights...whats the project name?
[01:09] <shtylman> system-config-printer-tool?
[01:10] <shtylman> and you mean the thing under system settings -> printer configuration?
[01:11] <shtylman> hehehe...git .. and not hosted in lp :)
[01:12] <Riddell> yes that's the one
[01:12] <Riddell> system-config-printer-kde
[01:12] <Riddell> it's in kdeadmin
[01:12] <shtylman> k
[01:12] <Riddell> it's a port of system-config-printer which is a gnome tool and somewhere in fedora's git hosting
[01:13] <Riddell> there's bits still needing ported, bits needing fixed, then the usability plan to be applied
[01:13] <shtylman> so do I just pull all of kdeadmin/ubuntu code? or can I just get the printer config part?
[01:13] <Riddell> get it from KDE SVN
[01:13] <shtylman> k
[01:13] <shtylman> ahh so this is upstream related...
[01:14] <Riddell> it's developed by Kubuntu and generously donated upstream
[01:14] <shtylman> :)
[01:14] <shtylman> any idea where it is located in the svn? off the top of your head
[01:14] <Riddell> it's the sort of thing upstream isn't very good at (geeks don't care about printing) but distros are (our users do print)
[01:14] <shtylman> the kde svn is a web of doom
[01:14] <Riddell> trunk/KDE/kdeadmin
[01:14] <shtylman> thx
[01:17] <shtylman> where is that spec?
[01:17] <shtylman> that I am supposed to follow...
[01:17] <Riddell> well the spec is just get the gnome version and port it to KDE
[01:17] <shtylman> alrighty :)
[01:18] <Riddell> then there's a .pdf file in the sources with seele's design
[01:18] <Riddell> so get it running and see what's missing compared to the gnome version
[01:18] <Riddell> (they layout of the gnome version has changed since to the fileview layout)
[01:19] <shtylman> alright...I just pulled the gnome version
[01:19] <shtylman> lemme try to get the running
[01:19] <shtylman> from git
[01:19] <shtylman> and then try to get the kde one running
[01:19] <shtylman> and then go from there ...
[01:23] <shtylman> is anyone else currently on this?
[01:24] <shtylman> or has it sorta been orphaned?
[01:24] <Riddell> nope
[01:24] <Riddell> well it's always on my Todo
[01:24] <Riddell> but not reached the top yet this cycle
[01:24] <shtylman> heh...I see
[01:24] <shtylman> does it ever?
[01:27] <Riddell> it did for a bit last cycle
[01:27] <shtylman> well...I can't promise any miracles...but I will "look into it" :)
[01:30] <seele> Riddell: it did? for a few hours near the end of feature freeze?
[01:34] <shtylman> alright...well got the gtk one running...
[01:34] <shtylman> so you want a clone...??
[01:35] <seele> there ought to be a printing page somewhere with a design spec
[01:35] <seele> there were several functionality differences
[01:36] <shtylman> seele: well..I have the pdf that is in trunk
[01:36] <shtylman> but I swear...I have seen this functionality in kde already...havn't I?
[01:37] <shtylman> anyhow..ok...just give me ALL the info ya got..and I can go from there :)
[01:37] <seele> the functionality or the ui? there was a kde3 printer config tool
[01:37] <Riddell> seele: for at least a day
[01:37] <Riddell> shtylman: it's been in KDE 4 for a few releases now, but it's not complete
[01:37] <seele> Riddell: oooh, a full day? sorry about the underestimation
[01:38] <shtylman> Riddell: its the one we all currently use right?
[01:38] <Riddell> shtylman: yes
[01:38] <shtylman> and yall just want it brought up to speed and make "prettier" and more "usable"
[01:39] <shtylman> make sure i understand :)
[01:39] <shtylman> Riddell: the version I pulled from trunk...can I run that independently? or is there a special "run this module" command i need??
[01:42] <shtylman> holy shit...it is 4k lines?. ..
[01:42] <shtylman> jesus :)
[01:42] <shtylman> that will need to be put into separate files...
[01:42] <Riddell> it needs installed into /usr/share/kde4/apps/system-config-printer-kde
[01:42] <shtylman> k
[01:42] <Riddell> then run kcmshell4 system-config-printer-kde
[01:43] <shtylman> so I can just modify the system files there if I want?
[01:43] <shtylman> modify in place and whatnot...
[01:44]  * DaskreeCH yawns
[01:44] <DaskreeCH> Ok Where are we ? :)
[01:44] <shtylman> lost :)
[01:45] <Riddell> shtylman: yes you can
[01:46] <Riddell> shtylman: I typically work on it in bzr in a branch somewhere under https://code.edge.launchpad.net/system-config-printer then dump it back to KDE when it's ready
[01:47] <shtylman> Riddell: noted
[01:47] <DaskreeCH> seele: ping
[01:54] <shtylman> should I go with what is in trunk as a starting point? or your branch Riddell?
[01:55] <Riddell> I don't think I have a current branch
[01:55] <seele> DaskreeCH: pong
[01:55] <shtylman> lp:system-config-printer  ??
[01:55] <shtylman> or is that a mirror of svn?
[01:56] <DaskreeCH> seele: would kuser in System settings be a paperkut?
[01:56] <Riddell> right that's what I worked on last, it was synced to svn once I finished so go with svn
[01:56] <shtylman> ahh ok...gotcha
[01:56] <Riddell> DaskreeCH: it's a whole application, hardly a papercut
[01:57] <DaskreeCH> Riddell: It's not like it doesn't exist it does
[01:57] <DaskreeCH>  it just doesn't turn up in system settings
[01:57] <seele> DaskreeCH: uh.. no
[01:57] <seele> that sounds like a bug, not a design problem
[01:57] <DaskreeCH> Can't recall why right now
[01:59] <DaskreeCH> ah paperkuts are design issues
[01:59] <DaskreeCH> I'd probably have to think about those for a while.
[01:59] <DaskreeCH> Defaults don't count then?
[01:59] <seele> uhm.. well the program exists as a design project so yeah
[01:59] <seele> depends
[01:59] <DaskreeCH> on?
[02:00] <seele> on the default? why it is being changed? what needs done to change it?
[02:00] <seele> i cant really make a sweeping generalization that all default changes are papercuts or related to design issues
[02:01] <DaskreeCH> Well I meant in a kubuntu sense of the word most defaults are just taken from KDE so it would more be an issue of should it be changed in Kubuntu or upstream
[02:01] <DaskreeCH> which entails a larger discussion than just a karmic release I would suppose
[02:02] <DaskreeCH> I've been really distracted this cycle so I haven't even been doing thorough bug hunting on the KDE 4.3 release :(
[02:02] <DaskreeCH> I'm trying to make it up by finding some paperkuts for the karmic release :)
[02:03] <DaskreeCH> Side note anyone been running Koffice ?
[02:03] <DaskreeCH>  I tried to install Krita and it made me install the KDE 3 version
[02:05] <ScottK> IIRC upstream declared the KDE 4 one "not ready".
[02:06] <DaskreeCH> Yes I know but there for testing
[02:07] <DaskreeCH> I had actually intended to use Krita (KDE3 version is waaay nicer btw) so it's not a complaint I was just wondering why when I had the Koffice 2 RC instaleld it would prefer the Krita KDE3 version
[02:07] <ScottK> If you want KDE4 one, install krita-kde4.
[02:08] <DaskreeCH> Ah that would probably be it
[02:08] <DaskreeCH> doing this at 3:00 might have clouded that :)
[02:08] <ScottK> Perhaps.
[02:09] <DaskreeCH> Hmm I thik that having the person's name from the install should make an entry in the Kaddressbook but that's probably not a paperkut either
[02:10] <DaskreeCH> Does the quick access plasmoid in KDE 4.3 RC3 have a tooltip on hover for anyone?


[15:00]  * marjo waves
[15:00] <zul> hi
[15:00]  * skaet waves
[15:00] <skaet> hi all
[15:00] <pitti> o/
[15:01] <cjwatson> hi
[15:01] <skaet> #startmeeting
[15:01] <MootBot> Meeting started at 10:01. The chair is skaet.
[15:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[15:01] <cjwatson> dear wiki, stop 500ing when I'm trying to read you
[15:01] <skaet> [Topic] Natty overview - skaet_
[15:01] <skaet> Reminder:   please use ".." on separate line when you've finished typing.   If someone wants to comment during the updates, please "o/", so we know to wait.
[15:01] <skaet> .
[15:01] <skaet> Agenda is at:
[15:01] <skaet> [LINK] https://wiki.ubuntu.com/ReleaseTeam/Meeting/2011-03-25
[15:01] <MootBot> New Topic:  Natty overview - skaet_
[15:01] <MootBot> LINK received:  https://wiki.ubuntu.com/ReleaseTeam/Meeting/2011-03-25
[15:01] <skaet> .
[15:01] <skaet> User Interface Freeze and Beta Freeze came into effect March 24th (at 2300 UTC ), so now on the focus is on getting the Beta images ready for the wider audiences!
[15:01] <skaet> .
[15:01] <skaet> Awesome progress on closing out some of those high/critical bugs over the last week!   By my count - over 65 of the bugs we were monitoring for the release moved into a resolved state.   :)  Thanks to all involved!!
[15:01] <skaet> .
[15:01] <skaet> As of 2011/03/24 bugs for Natty that are are targetted for fixing were broken down as follows:
[15:01] <skaet>       * kernel:   linux: 7  drivers: 5
[15:01] <skaet>       * foundations:  19
[15:01] <skaet>       * server: 6
[15:01] <skaet>       * desktop: 14
[15:02] <skaet>       * ubuntuone: 2
[15:02] <skaet>       * kubuntu: 6
[15:02] <skaet>       * desktop experience: 26
[15:02] <skaet>       * arm: 9
[15:02] <skaet> .
[15:02] <skaet> This is still up from where we were with maverick, so appreciate the continued focus on it.
[15:02] <skaet> .
[15:02] <skaet> Milestoned bugs for beta 1 can be found:
[15:02] <skaet> [LINK] https://bugs.launchpad.net/ubuntu/+bugs?field.milestone=33574.
[15:02] <MootBot> LINK received:  https://bugs.launchpad.net/ubuntu/+bugs?field.milestone=33574.
[15:02] <skaet> Bugs targetted for this release can be found:
[15:02] <skaet> [LINK] https://bugs.launchpad.net/ubuntu/natty/+bugs
[15:02] <MootBot> LINK received:  https://bugs.launchpad.net/ubuntu/natty/+bugs
[15:02] <skaet> .
[15:02] <skaet> Note that the renaming of beta to beta-1 caused some links to become inaccurate.  If you spot any that are broken, please let me know.
[15:02] <skaet> .
[15:02] <skaet> Upcoming Significant Dates:
[15:02] <skaet> Beta 1 Release is March 31st.    :)
[15:02] <skaet> .
[15:02] <skaet> Freeze windows for beta 2 and the final images are still under discussion,  but we'll likely be going with Scott's recommendations for the back part of the cycle (and staying in beta freeze for now).   If no one has further comments by end of day today,  I'll go ahead and broadcast out the revised freeze dates on ubuntu-release mail list for those interested.
[15:02] <skaet> .
[15:02] <skaet> questions?
[15:02] <skaet> ..
[15:02] <skaet> any general questions about the release before we go into the round table?
[15:03]  * skaet is hoping we have a working IRC channel today...
[15:04] <skaet> marjo,  are you able to see this?
[15:04] <marjo> skaet: yes, looks fine on my end
[15:04] <skaet> great thanks,
[15:04] <skaet> lets head into round table then if no questions.
[15:05] <skaet> [Topic] QA team update - marjo
[15:05] <MootBot> New Topic:  QA team update - marjo
[15:05] <marjo> hi folks
[15:05] <marjo>  * Natty Beta 1 Work Items
[15:05] <marjo> Natty Beta-1 Work Items
[15:05] <marjo> https://launchpad.net/ubuntu/+spec/cloud-server-n-uec-qa
[15:05] <marjo> hggdh still blocked due to lack of working UEC since after Alpha 2. Blocked on Critical bug 717166
[15:05] <marjo> https://blueprints.edge.launchpad.net/ubuntu/+spec/ubuntutheproject-qa-n-laptop-testing-tracker
[15:05] <marjo> All done. Thanks to primes2h and ara for their work on this.
[15:05] <marjo>  * Natty boot regression report
[15:05] <marjo> http://people.canonical.com/~brian/daily-bootcharts/
[15:05] <marjo> Bug reports will be submitted by bdmurray
[15:05] <MootBot> LINK received:  http://people.canonical.com/~brian/daily-bootcharts/
[15:05] <marjo> sorry wrong link
[15:06] <marjo> http://people.canonical.com/~brian/daily-bootcharts/index.html
[15:06] <MootBot> LINK received:  http://people.canonical.com/~brian/daily-bootcharts/index.html
[15:06] <marjo>  * Natty Blocking bugs
[15:06] <marjo>  bug 717166
[15:06] <marjo>  * QA Dashboard
[15:06] <marjo>  http://reports.qa.ubuntu.com/reports/qadashboard/qadashboard.html
[15:06] <marjo> Note linux, unity, ubiquity and firefox are all in both the "Last Day" and "Last 7 Days" metrics.
[15:07] <marjo>  * Testing status:
[15:07] <marjo>  Desktop Automated Testing results
[15:07] <marjo> http://reports.qa.ubuntu.com/reports/desktop-testing/natty/
[15:07] <marjo> List of bugs found is at the bottom of page.
[15:07] <marjo>  Server Automated Testing results
[15:07] <marjo>  http://<IP_ADDRESS>/view/ISO-server-Natty/?
[15:07] <MootBot> LINK received:  http://reports.qa.ubuntu.com/reports/desktop-testing/natty/
[15:07] <marjo>  1 test failed. hggdh will investigate.
[15:07] <marjo>  Desktop and Alternate Image Testing results
[15:07] <marjo>  http://<IP_ADDRESS>:8080/view/natty-desktop/?
[15:07] <marjo>  Desktop tests are currently disabled. Alternates pass.
[15:07] <marjo> jibel is investigating failures on desktop images
[15:07] <marjo>   Automatic Upgrade Testing
[15:07] <marjo>  1 test failed.
[15:07] <marjo>  sudo problem that causes the post-upgrade test to fail is fixed, but not yet in the archive, due to the freeze. Once its in, it should make all but main-all and python-all green.
[15:07] <marjo>  Thanks to IS team for the bigger harddisk that enables the additional python-all test
[15:08] <marjo>  * Nvidia drivers Unity testing
[15:08] <marjo> http://reports.qa.ubuntu.com/reports/graphics_testing/natty/
[15:08] <marjo> 	* 34 different nVidia graphics cards have been tested
[15:08] <marjo> 	* 20 bug reports have been submitted; 3 are high importance
[15:08] <MootBot> LINK received:  http://reports.qa.ubuntu.com/reports/graphics_testing/natty/
[15:08] <marjo> ..
[15:08] <skaet> Thanks Marjo!
[15:08] <skaet> How did the ubiquity bug day go yestereday?
[15:10] <marjo> skaet: will get you stats on that
[15:10] <skaet> thanks marjo.  :)
[15:10] <skaet> any one else have questions for marjo?
[15:10] <skaet> [Topic] Hardware Certification team update - victorp
[15:10] <MootBot> New Topic:  Hardware Certification team update - victorp
[15:11]  * skaet looks around for victorp or ara
[15:12] <skaet> hmm... ok,  lets move on and circle back to hardware cert at the end
[15:12] <skaet> [Topic] Security team update - jdstrand
[15:12] <MootBot> New Topic:  Security team update - jdstrand
[15:13] <jdstrand> hi
[15:13] <skaet> :)
[15:13] <jdstrand> [LINK] https://wiki.ubuntu.com/SecurityTeam/ReleaseStatus/Natty
[15:13] <MootBot> LINK received:  https://wiki.ubuntu.com/SecurityTeam/ReleaseStatus/Natty
[15:13] <jdstrand> [LINK] http://people.canonical.com/~platform/workitems/natty/canonical-security.html
[15:13] <MootBot> LINK received:  http://people.canonical.com/~platform/workitems/natty/canonical-security.html
[15:13] <jdstrand> All work items tied to the release process are completed.
[15:13] <skaet> sweet
[15:13] <jdstrand> (though we have several remaining)
[15:13] <jdstrand> In terms of milestoned bugs, after talking with pitti and doko, micahg is planning on fixing bug #663294 by rebuilding with gcc-4.4. We fixed several others (see the above report). As usual, team has been focusing primarily on stable release updates.
[15:13] <jdstrand> Dealt with various FTBFS due to multiarch fallout. Members of my team have come across this several times already. Is there a plan to ensure buildability for supported packages? Is the archive going to be rebuilt?
[15:14] <jdstrand> ..
[15:14] <skaet> thanks jdstrand
[15:14] <skaet> we need to get the plans for the multiarch fleshed out,  and work with slangasek on that
[15:14] <skaet> expect it to be the subject of discussion at UDS ;)
[15:15] <jdstrand> well
[15:15] <jdstrand> it needs to be worked out prior to then, at least in terms of building from source
[15:15] <jdstrand> otherwise my team won't be able to effectively update packages in natty stable
[15:15] <cjwatson> I think we have a test rebuild due ...
[15:16] <skaet> [action] slangasek, jdstrand, skaet work through update packages issue for natty stable.
[15:16] <MootBot> ACTION received:  slangasek, jdstrand, skaet work through update packages issue for natty stable.
[15:16] <jdstrand> cjwatson: is that part of the release interlock or you saying "yeah, we need to do that"
[15:16] <cjwatson> I can't find the dates, but I was under the impression that it was scheduled
[15:16] <cjwatson> I'll need to check with doko though
[15:16] <jdstrand> ok cool
[15:17] <jdstrand> skaet: care to add doko to that action?
[15:17] <skaet> will do
[15:17] <jdstrand> that's it from me
[15:18] <skaet> Thanks for bringing up the issue.
[15:18]  * jdstrand nods
[15:18] <skaet> any other questions?
[15:18] <marjo> o/
[15:18] <skaet> go marjo
[15:18] <marjo> https://wiki.ubuntu.com/UbuntuBugDay/20110324
[15:18] <marjo> Low level of activity, but some people weren't using the bug day wiki page for some reason. bdmurray will investigate.
[15:18] <marjo> ..
[15:18] <skaet> thanks.
[15:19] <skaet> will follow up with you offline.
[15:19] <skaet> [Topic] Kernel team update - ogasawara
[15:19] <MootBot> New Topic:  Kernel team update - ogasawara
[15:19] <marjo> skaet: ack
[15:19] <ogasawara> Overall status is reported at the first link below.  Burn down for the release milestone is at the second link below.  Burndown for the cycle is at the third link:
[15:19] <ogasawara> [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Natty
[15:19] <ogasawara> [LINK] http://people.canonical.com/~platform/workitems/natty/canonical-kernel-team-ubuntu-11.04-beta-1.html
[15:19] <ogasawara> [LINK] http://people.canonical.com/~platform/workitems/natty/canonical-kernel-team.svg
[15:19] <MootBot> LINK received:  https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Natty
[15:19] <MootBot> LINK received:  http://people.canonical.com/~platform/workitems/natty/canonical-kernel-team-ubuntu-11.04-beta-1.html
[15:19] <MootBot> LINK received:  http://people.canonical.com/~platform/workitems/natty/canonical-kernel-team.svg
[15:19] <ogasawara> The remaining ubuntu-11.04-beta milestone work items are not critical to the release and should start to move to completion within the next week. The Natty distro kernel is now at v2.6.38-7.38 however we still need to upload v2.6.38-7.39 which is a no-change upload to rebuild against the new compiler update. This will require a beta freeze exception which I've already notified skaet about. Beyond this we do not anticipat
[15:19] <ogasawara> e any further uploads of the kernel until after Beta. We continue to track the upstream stable v2.6.38.y kernel as we move forward and have recently rebased to upstream stable v<IP_ADDRESS> which will be in the first post Beta upload.
[15:19] <ogasawara> Of the bugs called out on the agenda against the kernel, status is as follows:
[15:19] <ogasawara> #539467 SATA alpm is now disabled in userspace, possible fix for Nvidia mcp65 controllers when in minimal power mode has been tested with positive feedback;
[15:19] <ogasawara> #542660 testing with v2.6.38 final still problematic, needs further investigation.
[15:19] <ogasawara> #625364 looks possible to work around using a pm-utils quirk;
[15:19] <ogasawara> #630748 remains waiting on Intel for updated wireless firmware;
[15:19] <ogasawara> #634487 workaround exists, but proper fix still needs investiagion.
[15:19] <ogasawara> #707353 Fix released in linux-firmware-1.49.
[15:19] <ogasawara> #712075 partial fix in place, testing requested with 2.6.38 final kernel;
[15:20] <ogasawara> Questions?
[15:20] <ogasawara> ..
[15:20] <skaet> Thanks ogasawara!
[15:20]  * skaet looks around...
[15:21] <skaet> [Topic] Foundations team update - cjwatson
[15:21] <MootBot> New Topic:  Foundations team update - cjwatson
[15:21] <cjwatson> Lots of good bug progress this week.  That mad plymouth segfault should be dead, Michael fixed sudo upgrades, Surbhi fixed RAID1 boot degraded mode, and we landed the changes to avoid involving vesafb in the boot process unless we have to (which is huge for text-free boot, and has apparently made a significant dent in the visible bug flow).
[15:21] <cjwatson> Surbhi is making good progress on converting the initramfs to Upstart, although this is for Oneiric.
[15:21] <cjwatson> We do still have several high-priority bugs open for beta-1:
[15:21] <cjwatson>  * 671016: Alejandra Obregon has offered to help design this landing page.  It may slip beyond beta-1, though.
[15:22] <cjwatson>  * 728611: I can't reproduce this on my test systems so far, so will take more effort
[15:22] <cjwatson>  * 730759: under discussion with MIR team
[15:22] <cjwatson>  * 736111: if this is going to be fixed, I think it may need to be a workaround by the ARM team
[15:22] <cjwatson>  * 739400, 739489: uncertain of status, but these were recently filed by Evan and assigned to himself so I assume he's on top of them
[15:22] <cjwatson>  * 737603: active discussion between James and Steve - I'm not clear on whether openjdk-6 actually needs to change here, or whether it's all in libjna-java
[15:22] <cjwatson> The count is still fairly significant, but I'm pretty sanguine about our state at the moment.
[15:22] <cjwatson> Working on rolling out data.tar.xz and orig.tar.xz support in Launchpad.  We're nearly there.
[15:22] <cjwatson> ..
[15:22] <skaet> thanks cjwatson
[15:22] <skaet> In your mind,  we'll finally be good for WUBI testing again with beta?
[15:23]  * skaet thinks all the blockers are gone, but wants to double check.
[15:23] <cjwatson> I think so, though there are still a few odd bugs lurking
[15:23]  * skaet nods
[15:24] <cjwatson> bug 741859 came up yesterday evening and I don't understand it
[15:24] <cjwatson> so, yeah, work required
[15:24] <skaet> fair enough for this part of the cycle.
[15:24] <skaet> nice work on getting so many of the bugs closed last week.  :)
[15:24] <skaet> any other questions?
[15:25] <skaet> [Topic] Server team update - zul
[15:25] <MootBot> New Topic:  Server team update - zul
[15:25] <zul> Hi
[15:25] <zul> We are behind the trend line for beta-1, but we have been busy. Ill be poking people to update their specs. Also we added an auberienge color scheme and the ubuntu command line. Bugs that have been nominated are the following:
[15:25] <zul> Outstanding bugs:
[15:25] <zul> Outstanding bugs:
[15:25] <zul> 561779 - squid - squid is not started on runlevel transition 1 -> 2.
[15:25] <zul> 	* need to update upstart relatively easy to do.
[15:25] <zul> 727286 - libvirt - apparmor is blocking libvirt-bin from accessing folders in "/
[15:25] <zul> 	* Fixed already in natty.
[15:25] <zul> 733914 - autofs5 - autofs races network interfaces, ends up not working
[15:25] <zul> 	* Upstart job needs to be updated and tested.
[15:25] <zul> 728088 - debian-installer - iscsi root (amd64) with or without auth fails to boot
[15:25] <zul> 	* Assigned to the canonical foundations team
[15:25] <zul> Ongoing bugs:
[15:25] <zul> 697753 - eucalyptus - bittorrrent recomendations prevents demotion
[15:25] <zul> 	* still pending upload
[15:25] <zul> 717166 - Eucalyptus - Broken with v4 isc-dhcp-server in Natty
[15:25] <zul> 	* still ongoing testing and debugging
[15:25] <zul> 580319 - dhcp3-server launches before upstart brings all interface, thus failing to start
[15:25] <zul> 	Assigned to JamesHunt
[15:25] <zul> 727342 - FE for open-vm-tools kernel module
[15:25] <zul> 	* test
[15:26] <zul> New bugs:
[15:26] <zul> 726769 - eucalyptus - Eucalytpus failed to install
[15:26] <zul> 735017 - php-fpm failed to install if /var/www doesnt exist.
[15:26] <zul> i just noticed 726769 so Ill get Daviey to work on it and the php-fpm bug is a known bug that has already been fixed in debian we just have to cherry pick the fix
[15:26] <zul> ...
[15:26] <jdstrand> zul: I fixed bug #727286 last week. not sure why it is still on your list
[15:26] <skaet> thanks zul!
[15:26] <zul> jdstrand: yeah i noticed this morning as well thanks!
[15:27] <zul> i suspect alot of these bugs will be fixed after the beta
[15:27] <skaet> re:  727342, I thought that Daviey tested it and was good with it?
[15:27]  * skaet hopes zul's right ;)
[15:27] <zul> the open-vm-tools one? i thought serge was still asking for testers
[15:28] <skaet> yeah,  that's the one.
[15:28] <zul> ill double check
[15:28] <skaet> ok,  we'll look into it more offline then.
[15:28] <skaet> thanks
[15:28] <skaet> any other questions?
[15:28] <skaet> [Topic] Desktop team update - pitti
[15:28] <MootBot> New Topic:  Desktop team update - pitti
[15:28] <pitti> General status:
[15:28] <pitti>  * We made great progress with eliminating the old xulrunner-1.9.2 and also xulrunner-2.0 from main, as these are now pretty much unsupportable after the recently announced changes for Firefox' release schedule. Bug 740815 coordinates the work, still some things to do post-b1
[15:28] <pitti>  * New natty langpacks will be uploaded Sunday evening. Firefox search plugins will be back.
[15:28] <pitti>  * i386 CD oversized by 5 MB; that will be rectified by fresh langpacks, and eliminating some egl packages which we currently pull in through libcairo. We need to split out the GL backend, as it causes ridiculous memory leaks with the NVidia driver, and is only required for wayland.
[15:28] <pitti> Blueprint implementation:
[15:28] <pitti>  * On track for entire cycle
[15:28] <pitti>  * Remaining work for Natty:
[15:28] <pitti>   * unity a11y: We decided to give this one more week after beta (i. e. one release cycle), and if it's not good enough by then, we'll default to the classic GNOME session for the a11y profiles which need screen reading
[15:29] <pitti>   * Some remaining porting to xulrunner-2.0/webkit (see above)
[15:29] <pitti>   * Some remaining upgrade migration for deprecated applets
[15:29] <pitti>   * Various "test that this works", discuss user testing
[15:29] <pitti> RC bugs:
[15:29] <pitti>  * as usual, on https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus#rcbugs
[15:29] <pitti>  * For the ones we can't realistically fixed we now got contingency plans and workarounds, so we should make some good progress there right after b1 (maybe some fixes can still slip in)
[15:29] <pitti> ..
[15:29] <skaet> Thanks pitti!
[15:29] <pitti> sorry for the FFE rush for xulrunner, but we'll go insane if we don't do it
[15:30] <pitti> (that hit us pretty unexpectedly..)
[15:30] <jdstrand> pitti: thanks for working on it :)
[15:31] <skaet> understood,  it happens.   will look into your contingency plans for the rcbugs offline and get back to you.
[15:31] <skaet> any other questions?
[15:31] <skaet> [Topic] Ubuntu One Team - Chipaca or joshuahoover
[15:31] <MootBot> New Topic:  Ubuntu One Team - Chipaca or joshuahoover
[15:32]  * skaet looks for Chipaca_ ?
[15:33] <Chipaca_> I'm afraid I haven't done my homework this week; the status page will be updated next week
[15:33] <skaet> hmm, something must have happened,  will circle back at end then.
[15:33] <Chipaca_> that's https://wiki.ubuntu.com/UbuntuOne/NattyReleaseStatus
[15:33] <skaet> ok
[15:33] <Chipaca_> on the FFE front, bindwood is pretty much done, yay :)
[15:33] <skaet> Thanks,  please send me a ping when I can look at it then.
[15:33] <Chipaca_> ..
[15:34] <Chipaca_> (sorry)
[15:34] <skaet> Thanks Chipaca_  will get with you off line.  Can you please update this agenda with your comments after you get the summary figured out?
[15:35] <Chipaca_> skaet: sure. Actually I'll get joshua to do it :)
[15:35] <skaet> [ACTION] Chipaca_/Joshua to add ubuntu one summary directly to 2011-03-25 agenda status page.
[15:35] <MootBot> ACTION received:  Chipaca_/Joshua to add ubuntu one summary directly to 2011-03-25 agenda status page.
[15:35] <skaet> :)
[15:35] <skaet> thanks!
[15:35] <skaet> any questions?
[15:35] <skaet> [Topic] Kubuntu Team update - Riddell
[15:35] <MootBot> New Topic:  Kubuntu Team update - Riddell
[15:35] <Riddell> hi
[15:35] <skaet> :)
[15:36] <Riddell>  * CDs in decent shape for beta
[15:36] <Riddell>  * switching Qt to opengles on ARM means fixes needed to packages which use opengl, workaround in progress.  I've also been helping linaro folks package kwin for opengles
[15:36] <Riddell>  * Qt security fix for Comono fake SSL certificates in natty
[15:36] <Riddell>  * Qt accessibility bridge in ppa:jr if anyone wants to test
[15:36] <Riddell>  * KDE SC 4.6.2 due out the Tuesday after Beta 1
[15:36] <Riddell>  * http://goo.gl/23eui 10 bugs milestoned for beta
[15:37] <skaet> ..?
[15:37] <Riddell> ..
[15:37] <skaet> :)  Thanks.
[15:37] <skaet> of the 6 bugs called out in the agenda,   do they actively have someone working them,  or are they in limbo.
[15:37] <victorp> skaet - when is the release meeting?
[15:37]  * skaet hasn't dug into each individually yet this week...
[15:37] <Riddell> skaet: actually I don't know how to list those 6 bugs
[15:38] <skaet> Riddell,  ok, I'll get with you offline.
[15:38] <skaet> and see if we can figure out how to get an effective summary from both sides,  prob. after beta -1 though ;)
[15:38] <skaet> victorp, started 40 minutes ago.
[15:39] <skaet> victorp,  we'll call on you after the rest of the round table,  ok?
[15:39] <skaet> any other questions for Riddell?
[15:40] <skaet> Topic] Desktop Experience Team Update - dbarth
[15:40] <dbarth_> hi
[15:40] <skaet> :)
[15:40] <dbarth_> status report at: https://wiki.ubuntu.com/DesktopExperienceTeam/NattyReleaseStatus
[15:40] <dbarth_> some ffe news first
[15:40] <dbarth_> overlay scrollbar and multitouch integration are done and "green lighted"
[15:40] <dbarth_> we're blocked on a11y for places, trying to scope that down to just support alt-f2
[15:41] <dbarth_> (pitti was also mentioning it earlier)
[15:41]  * skaet nods
[15:41] <dbarth_> 2 new small FFEs for MT apps (see report)
[15:41] <dbarth_> for the rest, nice bug fix counters for both unity shell and foundations
[15:41] <pitti> dbarth_: oh, did sabdfl ack the scrollbar FFE? I didn't see that on the bug
[15:41] <dbarth_> not yet
[15:42] <dbarth_> Yet another batch of 60 bugs fixed this week! - see https://launchpad.net/unity/+milestone/3.6.8 - including
[15:42] <dbarth_> numerous crashers for compiz, its decorator, unity, nux or places
[15:42] <dbarth_> lots of UI tweaks, like a nice search progress signal
[15:42] <dbarth_> ?!
[15:42] <dbarth_> and
[15:42] <dbarth_> 20 bugs fixed in Foundations this week https://bugs.launchpad.net/unity-foundations/+milestone/unity-3.6.8, including
[15:42] <dbarth_> a lot more fixes for places, including a nasty crasher 737396
[15:42] <dbarth_> desktop menu update from Ted 692194
[15:42] <dbarth_> improvements in the ayatana-scrollbar 728418 and whitelist support 740276
[15:42] <dbarth_> ..
[15:42] <pitti> dbarth_: for a11y, my most recent knowledge is that Luke should test b1, and if it's not good enough, we'll use classic for profiles with screen reading?
[15:43] <dbarth_> b1 doesn't contain anything that can make alt-f2 work for him
[15:43] <dbarth_> we're trying to propose a patch on monday, but that won't go into the images anyway
[15:43] <dbarth_> after monday, we should drop the feature if we can't make it work
[15:44] <dbarth_> other questions?
[15:44] <skaet> ok.   will work with you around tuesday to make sure we've got the release notes appropriate for this release.
[15:45] <dbarth_> sure
[15:45] <skaet> btw - Thanks dbarth_!   awesome job on all those bug fixes getting in this week.
[15:45] <dbarth_> i'll pass that on to the team, thanks; they we're really on fire on wednesday night!
[15:45] <skaet> any other questions?
[15:45] <dbarth_> (were)
[15:45] <skaet> dbarth_, yes,  they were, and it was much appreciated.  :)
[15:46] <skaet> [Topic] ARM team update - ogra
[15:46] <MootBot> New Topic:  ARM team update - ogra
[15:46]  * ogra_ waves
[15:46] <ogra_> Status is at:
[15:46] <ogra_> [LINK] https://wiki.ubuntu.com/ARMTeam/ReleaseStatus/Natty
[15:46] <ogra_> ..
[15:46] <ogra_> Summary:
[15:46] <MootBot> LINK received:  https://wiki.ubuntu.com/ARMTeam/ReleaseStatus/Natty
[15:46] <ogra_>  * OMAP4 TI kernel has HDMI support again (image builds need to change boot cmdline before beta for this)
[15:46] <ogra_>  * PowerVR SGX drivers ported to .38 and already available at the TI PPA
[15:46] <ogra_>  * unity-2d was updated to the latest release (3.8) with about 60 bugs fixed.
[15:46] <ogra_>  * Mono ARM research is going on, NCommander thinks he has a workaround for the identified SMP issues on ARM with mono.
[15:46] <ogra_>  * ARM specific FTBFS list for main only has KDE packages left.
[15:46] <ogra_> ..
[15:46] <ogra_> Image status:
[15:46] <ogra_>  * Netbook images are currently broken, waiting for the archive to settle
[15:46] <ogra_>  * New headless/serial image works fine but is broken due to new kernel upload atm.
[15:47] <ogra_> ..
[15:47] <ogra_> Specs:
[15:47] <ogra_> Entire status: http://people.canonical.com/~platform/workitems/natty/ubuntu-armel.html
[15:47] <ogra_> Milestone: http://people.canonical.com/~platform/workitems/natty/ubuntu-armel-ubuntu-11.04-beta-1.html
[15:47] <ogra_> ..
[15:47] <ogra_> Bugs:
[15:47] <ogra_>  * 619981
[15:47] <ogra_>  * 721531
[15:47] <ogra_>  * 633227
[15:47] <ogra_> ..
[15:48]  * skaet notes that ogra's separators are the same as .. for end.   not sure if he's done?
[15:48] <ogra_> heh
[15:48] <ogra_> should i use two separators at the end of my paste in the future ?
[15:48] <ogra_> :)
[15:48] <ogra_> ..
[15:49] <skaet> Thanks ogra!   does it look like we'll be able to resolve all the ARM FTBFS for KDE by monday?
[15:49] <skaet> yup, 2 separators would work.  :)
[15:49] <ogra_> not sure, the gles bits seem to require some bigger changes for some apps
[15:50] <skaet> ok,   what about the 9 bugs on the agenda?
[15:50] <ogra_> but i think not all apps that ftbfs are on the images
[15:50] <ogra_> i will look over them, some shouldnt be milestoned at all
[15:51] <skaet> ok, please do.
[15:51] <ogra_> bug 728335 seems to not be arm related
[15:51] <ogra_> i have no idea why cross toolchain bugs show up on our list
[15:51] <skaet> if they're not appropriate, that's also what I want to know.   So I can make sure they're not orphaned.
[15:52] <ogra_> they are linaro
[15:52] <skaet> feel free to cut/paste them there, when you see it.
[15:52] <ogra_> i'll go over the list piece by piece offline before beta and talk to you if they are wrongly assigned
[15:52] <skaet> generally if they have armel tag,  I use that as indicator.
[15:52] <skaet> great
[15:52] <skaet> thanks!
[15:52] <ogra_> thats definitely wrong
[15:53] <ogra_> armel covers everything thats armel :)
[15:53] <ogra_> not team specific at all
[15:53]  * skaet is happy to figure out some better heuristics with ogra...  :)
[15:53] <ogra_> only hw specific ...
[15:53] <ogra_> ..
[15:53] <skaet> yeah
[15:53] <skaet> any other questions for ogra?
[15:53] <skaet> [Topic] MOTU team update - ScottK
[15:53] <ogra_> we usually subscribe the ubuntu-armel team to the bugs we're intrested in
[15:53] <MootBot> New Topic:  MOTU team update - ScottK
[15:54] <ScottK> Hello
[15:54] <ScottK> We were going to discuss a mass giveback at this meeting.
[15:54] <ScottK> armel's just been done, so no need to do it again.
[15:54] <ScottK> I think we ought to do i386/amd64/powerpc.
[15:54] <ScottK> ..
[15:55] <skaet> ok,  things I'm aware of happening are the kernel builds.
[15:55] <skaet> cjwatson,  pitti,  what do you estimate the builder loads will be like?
[15:55] <ScottK> The retries are almost all Universe so shouldn't block stuff in Main at all.
[15:55] <ScottK> If we do it today, it'll be done before Monday.
[15:56] <pitti> skaet: I think we should do it now to make use of the weekend
[15:56] <pitti> and i386/amd64 are empty right now, it's just arm struggling
[15:56] <pitti> so, +1 from me
[15:56] <cjwatson> right, I can check why all those buildds are disabled
[15:56] <skaet> ok, sounds like we should be good to do it then.
[15:56] <cjwatson> and if armel's just been done, that answers that part of it
[15:56] <cjwatson> so yeah, let's do it
[15:56] <ScottK> It has.
[15:57] <pitti> cjwatson: the first three are known to lamont; it's not a spurious disconnect which we can just re-enable
[15:57] <pitti> skaet: and there won't be too much gardening of unapproved over the weekend; and if so, we can always bump their build score
[15:57] <cjwatson> yup
[15:57] <skaet> pitti, cjwatson, ScottK - sounds like should be fine.  lets go for it.
[15:58] <cjwatson> I'll take care of it (either directly or via lamont)
[15:58] <ScottK> Great.
[15:58] <skaet> ScottK,  you pulling the trigger?
[15:58] <cjwatson> 15:58 <cjwatson> I'll take care of it (either directly or via lamont)
[15:58] <ScottK> skaet: I have no trigger.
[15:58] <skaet> oops
[15:58]  * skaet interpretted cjwatson
[15:58] <ScottK> I will write an email to warn people.
[15:59] <skaet> comments about the builders not working rather than the start of the give back
[15:59] <skaet> thanks cjwatson
[15:59] <cjwatson> oh, right, yeah, I meant the give-back
[15:59] <skaet> thanks for writing the warning note ScottK
[15:59] <skaet> :)
[15:59] <skaet> any questions for ScottK?
[16:00] <skaet> [Topic] Linaro update - JamieBennett
[16:00] <MootBot> New Topic:  Linaro update - JamieBennett
[16:00] <JamieBennett> o/
[16:00] <JamieBennett> So not much to report this week
[16:01] <JamieBennett> we uploaded a new kernel which fixed a tonne of bugs
[16:01] <JamieBennett> but the multi-arch stuff still continues to happen
[16:01]  * skaet nods
[16:01]  * victorp says hi
[16:01] <JamieBennett> the aim is for an integrated but not fully functional multi-arch story by end of cycle
[16:01] <JamieBennett> and a rocking 11.10
[16:02] <JamieBennett> so with that in mind we are just fixing issues that have happened due to the changes
[16:02] <JamieBennett> there are no other real intersections to report
[16:02] <JamieBennett> ..
[16:02] <skaet> fair enough.   Thanks JamieBennett
[16:03] <skaet> any questions for JamieBennett ?
[16:03] <doko_> ScottK: mass give back was done for all archs beginning of this week. why is another one needed?
[16:03] <ScottK> doko_: Was it done for all archs or just armel?
[16:03] <ScottK> If it was all archs, then it's not.
[16:03] <ScottK> (needed)
[16:03]  * ScottK thought it was just armel.
[16:05] <ScottK> doko_: A quick sampling I see !armel build failures older than this week.
[16:05] <ScottK> (I found 3/9 just checking a few)
[16:05] <skaet> [ACTION] doko, ScottK, cjwatson review what's still needed for the giveback and initiate for non-armel if necessary.
[16:05] <MootBot> ACTION received:  doko, ScottK, cjwatson review what's still needed for the giveback and initiate for non-armel if necessary.
[16:05] <skaet> victorp?  do you have stable connection?
[16:06] <victorp_> kind of
[16:06] <victorp_> trying webchat.freenode.net
[16:06] <victorp_> :)
[16:06] <victorp_> skaet I have emailed you my update
[16:06] <victorp_> anyone there?
[16:06] <skaet> yup
[16:07] <victorp_> ok - shall I go?
[16:07] <skaet> do you want to try posting,  so we don't have extra work
[16:07] <doko_> ScottK: they were given back, if there are new ones ... I don't know
[16:07] <skaet> yes please...  just sec.
[16:07] <skaet> Topic] Hardware Certification team update
[16:07] <victorp_> lets try
[16:07] <victorp_> This weeks coverage is the biggest that we got so far. Lab issues are being fixed and new systems that we plan to certify for 11.04 are being added. You can find the report in the usual location:
[16:07] <victorp_> [LINK] http://people.canonical.com/~hwcert/hw-testing/current
[16:07] <MootBot> LINK received:  http://people.canonical.com/~hwcert/hw-testing/current
[16:08] <victorp_> We keep improving our tests to reduce false negatives  Some issues:   * The bug about the Tecra R700 not suspending/resuming properly is still outstanding:
[16:08] <victorp_> [LINK] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/708286
[16:08] <MootBot> LINK received:  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/708286
[16:08] <victorp_> * Some of the new systems added this week are not pxe booting. This looks like a configuration issue and we are still investigating
[16:08] <victorp_> Also, we reported Bootmetrics to the QA team
[16:08] <victorp_> ..
[16:09] <marjo> victorp_ thx!
[16:09] <victorp_> marjo - no probs
[16:09] <skaet> thanks victorp_  :)
[16:09] <skaet> any questions?
[16:09] <skaet> [Topic] any other kudos/comments/questions?
[16:09] <MootBot> New Topic:  any other kudos/comments/questions?
[16:10]  * skaet looking around....
[16:10] <skaet> Thanks to marjo, jdstrand, ogasawara, cjwatson, zul, pitti, Chipaca_, Riddell, dbarth, ogra, ScottK, JamieBennett, victorp_, doko
[16:10] <skaet> #endmeeting
[16:10] <ogra_> thanks skaet
[16:10] <MootBot> Meeting finished at 11:10.
[16:10] <jdstrand> thanks skaet
[16:10] <marjo> skaet: thx!
[16:10] <Chipaca_> de nada, actually :-/
[16:11] <victorp_> skaet thx! will try to get a better connection for next week
[16:11] <skaet> Chipaca_, appreciate you following up with joshuahoover, and making sure there's something recorded.   so thanks are appropriate.
[16:11] <skaet> :)
[16:12] <skaet> thanks victorp,  looking forward to better connection and DST issues getting resolved.  :)
[16:12] <victorp> :) now is working fine
[16:12] <victorp> must be your meeting skaet ;)
[16:12] <doko_> jdstrand: archive rebuild still planned before the b1, but we need to fix basic multiarch things first, or else we see too many failures
[16:13] <skaet> victorp,  lol.  yeah keep that excuse,  it might even work ;)
[16:15] <jdstrand> doko_: noted. thanks
[16:17] <lamont> cjwatson: the buildds get disabled because the packages they're being asked to build so massively overtax the buildd that either (1) it falls over dead, or (2) launchpad decides it has, even though it hasn't.  in either case, launchpad then moves the build onto the next buildd and we knock that one over in turn
[16:17] <lamont> and since gcc, gcj, openjdk, and such are (1) examples, (2) needs-build/building, and(3) in main, it really really sucks to be a universe package
[16:18] <victorp> ;D


[13:21] <stgraber> highvoltage: just realized it's going to be the first time we'll have the whole Edubuntu council in the same room, we'll definitely need a photo of that :)
[13:29] <highvoltage> stgraber: wow, indeed. we should have a party!
[17:17] <stgraber> highvoltage: just got a working weblive session with both freenx and x2go. Took me an hour to debug freenx... for some reason they use "openssl md5" instead of "md5sum" which broke with the switch to the new ssl in oneiric...
[17:19] <highvoltage> ok
[20:53] <neodragon> hello
[20:56] <neodragon> I just install edubuntu 11.04 for my daughter and it is not recognizing the AC97 sound card on the motherboard
[22:18] <micahg> hi stgraber, did you see my note from yesterday?
[22:19] <stgraber> micahg: where?
[22:19] <micahg> above :)
[22:19] <micahg> shall I repost?
[22:20] <stgraber> nope, got it, sorry didn't notice before :)
[22:20] <micahg> np
[22:21] <stgraber> oh, one more team... is that what's done for the other <whatever>-dev that were created by the DMB but managed by some other team?
[22:22] <stgraber> (thinking of kubuntu-dev and ubuntu-desktop for these I remember)
[22:22] <micahg> well, this is the first case where I think it's an issue, ubuntu-desktop it was just seb128, so he's already an admin
[22:22] <micahg> stgraber: the main issue as highvoltage explained to me was that the Edubuntu Council shouldn't grant upload rights either
[22:23] <micahg> err..membership in that team shouldn't grant upload rights
[22:23] <stgraber> indeed, even though I think we're all in that team at the moment
[22:24] <stgraber> ah, except scotty but that's because he didn't read his e-mails ;)
[22:24] <stgraber> so yeah, we can create one more team but it may be worth poking the LP folks to eventually get a way of either having multiple owners or some kind of non-member administrator status
[22:26]  * micahg files bug
[22:27] <micahg> actually, let me poke the devs first to make sure I"m not missing something
[22:28] <stgraber> micahg: anyway, created edubuntu-dev-owner, invited DMB and edubuntu-council and made edubuntu-council the owner
[22:28] <micahg> stgraber: actually, I think DMB should be owner in this case, since upload approver is a delegation
[22:30] <stgraber> stupid launchpad... change the ownership to some stranger
[22:32] <micahg> stgraber: just find a LOSA to fix
[22:32] <stgraber> micahg: poked #launchpad
[22:33] <micahg> stgraber: please change edubuntu-dev back to the council until that's fixed
[22:35] <stgraber> micahg: only the owner can do that ;)
[22:35] <stgraber> ah right, nevermind :)
[22:36] <stgraber> micahg: done (for some reason I didn't realize I was still a member of -owner and so could easily change the owner of -dev for now ;))
[22:37] <micahg> stgraber: right, I would've have done it, but the DMB wasn't added as an admin of the new team
[22:38] <highvoltage> heh, just saw the emails come in. that was kind of weird :)
[22:38] <micahg> edubuntu-dev-owner shouldn't be a member of edubuntu-dev (fixed)
[22:39] <micahg> that's the problem we're trying to fix :)
[22:39] <stgraber> micahg: should be all good now
[22:41] <stgraber> micahg: I'm quite surprised kubuntu-dev isn't owned by the kubuntu council, might be worth poking them about it ;)
[22:41] <stgraber> or rather, isn't owner by kubuntu-council+dmb as for edubuntu-dev
[22:41] <micahg> stgraber: yeah, I'm working on that


[02:59] <genii> How does Noble get a dymanic IP, doesn't seem like dhclient is installed anymore
[03:04] <genii> ok, networkctl
[09:10] <machine> need to help with setting up ntp client
[09:30] <blahdeblah> machine: What have you tried so far?
[15:05] <deostroll> Hello world. Running an ubuntu-server in a virtualbox vm. Also running some software on it to play audio. (Wav files). Do I need to do anything on virtualbox to enable sound output?
[16:12] <Quark> deostroll: what drove you to pick ubuntu-server, instead of workstation?
[16:14] <Quark> deostroll: to address your question, I don't know. I think that's more of a VirtualBox question. Sadly, #virtualbox on Libera seems eerily quiet.
[17:12] <minimal> Quark: you mean the #vbox channel I assume, I don't see a #virtualbox channel. AFAIK the official channel is #vbox on OFTC, not Libera
[17:13] <Quark> minimal: there is a #virtualbox channel. I am currently in it; but as I wrote, it is almost empty.
[17:15] <Quark> minimal: thanks for mentioning #vbox!
[17:43] <deostroll> Oh, I was just trying something out. Anyway, I tried linux mint (desktop). On it I opened FF and visited YT and played a video. I could hear the sound. So this somewhat confirmed that pythonic play sound program would work, and, it did.
[17:45] <deostroll> So I am assuming something is amiss in the server installation that makes programs not recognize sound cards. And, at this point, I am too afraid to ask what is that...
[17:53] <Odd_Bloke> What's the software you're using?  Do you have anything under /dev/snd?
[18:22] <minimal> Quark: strange, my IRC client doesn't show #virtualbox
[18:22] <minimal> Quark: anyway my point was to NOT ask in #vbox on Libera, but to ask in #vbox on OFTC
[18:23] <minimal> there is at least one member of VB staff who is often present in #vbox on OFTC
[18:23]  * Quark gives thumbs up.
[18:30] <deostroll> python simpleaudio


[03:51] <tmart> Can someone explain how the ghelp url link work? Or if there is a link that will help explain?
[15:37] <arvind_khadri> hi, anybody out here?
[17:58] <robotgeek> nixternal: is there a task list for kubuntu docs for jaunty?
[19:48] <dsas> mdke: So it had, i've reopened it now