[00:07] <davecheney> cherylj: looks like CI is still running 1.2
[00:07] <davecheney> at least on the 1.25 branch
[00:08] <davecheney> does sinzui 's fix need to be backported to 1.25 ?
[00:08] <davecheney> >was it just that  the go compiler sucks compared to c++?
[00:08] <davecheney> ^ i literally cannot even
[00:09] <anastasiamac_> wallyworld: axw: i think this is ready to go http://reviews.vapour.ws/r/4573/ could someone plz stamp it? :D
[00:09] <sinzui> davecheney: What is happening here http://reports.vapour.ws/releases/3933/job/run-unit-tests-race/attempt/1387
[00:10] <davecheney> ta
[00:10] <wallyworld> sinzui: are all the juju tests now run on go 1.6?
[00:10] <wallyworld> for 2.0?
[00:10] <davecheney> the race detector does not support ppc64
[00:10] <davecheney> hang on
[00:10] <davecheney> is this ppc64
[00:10] <sinzui> wallyworld: no windows and centos are tested on both 1.2 and 1,6 because the 1.6 do not pass
[00:10] <davecheney> no, this is amazon
[00:11] <sinzui> davecheney: That is exactly my wtf moment. a trusty containter that thinks it is ppc
[00:11] <wallyworld> sinzui: that's the unit tests right?
[00:11] <sinzui> wallyworld: yes
[00:11] <davecheney> ok, so the race deector in the trusty golang1.6 deb is busted
[00:11] <davecheney> :9
[00:11] <davecheney> :(
[00:11] <davecheney> paging mwhudson
[00:12] <wallyworld> sinzui: i thought horatio fixed the windows tests on 1.6, i'll need to check
[00:12] <mwhudson> davecheney: ah yes
[00:12] <sinzui> wallyworld: no his last fix was for go 1.2 regressions
[00:12] <sinzui> wallyworld all packages have been built with go 1.6 for several weeks
[00:12] <mwhudson> davecheney: try https://launchpad.net/~mwhudson/+archive/ubuntu/trusty-race-detector/+packages ?
[00:13] <wallyworld> sinzui: the issue right now is there's some upstream azure sdk changes we need but those require go 1.6 to build, so we need 1.6 everywhere first
[00:13] <wallyworld> so those tests need fixing
[00:13] <sinzui> wallyworld: IU ask every day in meeting for them to be fixed
[00:14] <wallyworld> yeah, everyone is busy :-(
[00:15] <sinzui> davecheney: I am inclined to make the race tests non-voting until we sort out what happened
[00:17] <sinzui> wallyworld: in the case of windows, I see bugs we already see, but more often, and some that seem to have been revealed by recent fixes http://reports.vapour.ws/releases/3933/job/run-unit-tests-win2012-amd64-go1_6/attempt/51
[00:19] <wallyworld> sinzui: oh the fix for beta6 for ODS - the pinger shutdown fix - may have introduced a new window failure
[00:19] <sinzui> wallyworld: :(
[00:19] <wallyworld> well just just a guess
[00:19] <sinzui> wallyworld: I am on unknowns tomorrow. I will get every bug files for the remaining Go 1.6 tests
[00:20] <wallyworld> it seems go 1.6 on windows slowness may be exaserbating some of these failures
[00:20] <sinzui> wallyworld: and as for slowness. I think we need to extend timeouts for centos and windows
[00:20] <wallyworld> if that helps short term, that would be nice so we can get the azure fixes in
[00:23] <sinzui> wallyworld: I will also get that sorted out tomorrow
[00:23] <wallyworld> ok, ty
[00:36] <sinzui> davecheney: I think we need to force the race tests to run with go1.2 or quickly solve the golang 1.6 ld issue
[00:37] <davecheney> mwhudson: what say you to that ?
[00:37] <davecheney> afaik the race detector in go 1.6 works fine
[00:37] <davecheney> but something is wrong with how it's pacakged in trusty
[00:37] <mwhudson> ah
[00:37]  * redir is eod later #juju-dev
[00:37] <mwhudson> sinzui, davecheney: there is a ppa with the support files needed
[00:37] <mwhudson> https://launchpad.net/~mwhudson/+archive/ubuntu/trusty-race-detector/+packages
[00:37] <davecheney> sinzui: is using that ppa an option ?
[00:38] <mwhudson> sinzui, davecheney: i should get this into trusty too
[00:38] <mwhudson> sinzui, davecheney: alternatively, can you run the race tests on xenial?
[00:38] <sinzui> davecheney: yes, yes I think it is
[00:38] <davecheney> cool
[00:39] <sinzui> mwhudson: I just switched the tests to xenial. got the same error though
[00:39] <mwhudson> sinzui: oh that's more surprising
[00:39] <mwhudson> sinzui: do you have apt/apt-get installing recommends by default?
[00:41] <sinzui> mwhudson: no, but we support installing a different set of packages instead of using the makefile (tht is how we test s390x and arm64)
[00:41] <mwhudson> shouldn't matter
[00:41] <mwhudson> sinzui: can you link me to the log of it failing on xenial?
[00:42] <sinzui> mwhudson: It is happening right now at http://juju-ci.vapour.ws:8080/job/run-unit-tests-race/1388/console. You need to log in as a dveloper to see it
[00:44] <davecheney> can someone send me the developer credentials
[00:44] <davecheney> my browser has forgotten them
[00:47] <mwhudson> sinzui: how does the golang-1.6 package get installed there?
[00:47] <mwhudson> all i see is golang-1.6 is already the newest version (1.6.1-0ubuntu1).
[00:49] <mwhudson> sinzui: anyway, somehow the golang-1.6-race-detector-runtime package needs to get installed
[00:49] <mwhudson> sinzui: usually that gets installed when golang-1.6 does, because golang-1.6 Recommends: it
[00:49] <mwhudson> er golang-1.6-go Recommends it, to be more precise
[00:50] <mwhudson> sinzui: but if golang-1.6-go is somehow installed when recommends are disabled, it won't, so that's my guess as to what's happening here
[00:53] <sinzui> mwhudson: understood. The makefile forces no-recommends. the makefile got an update today to ensure golang 1.6 or higher is preffered. I will reconfigure the job to install the required packages.
[00:57] <mwhudson> sinzui: ah makes sense
[00:59] <axw> anastasiamac_: LGTM
[01:00] <anastasiamac_> axw: \o/
[01:01] <sinzui> thans not fair. the rules to install extra packages conflict with the rules run with --race
[01:05] <sinzui> oh, all is good. thank you mwhudson and davecheney . I can see golang-1.6-race-detector-runtime is installed and the tests are running with --race on xenial
[01:06] <mwhudson> sinzui: \o/
[01:20] <davecheney> woot
[02:41] <natefinch> menn0, axw, wallyworld:  anyone care for a quick review?  It's fairly trivial, but for a critical bug: http://reviews.vapour.ws/r/4735/
[02:42] <wallyworld> sure
[02:43] <natefinch> I'd gotten eric to review, but he had some questions, so I wanted another pair of eyes
[02:50] <wallyworld> natefinch: if we have test coverage for proper use of ssl via other means, then we probably can remove that special case in the test
[02:50] <natefinch> wallyworld: well, my static analysis tests are stuck in committee... so right now, we don't.
[02:51] <wallyworld> natefinch: ok, so no harm leaving it there for now. i think the pr is lgtm
[02:51] <natefinch> wallyworld: ok... i think that's basically where eric landed too, just wanted a second opinion.  Thanks.
[02:51] <wallyworld> np
[03:03] <natefinch> wallyworld: do you know if the apt mirrors thing is *only* applicable to MAAS?
[03:04] <wallyworld> natefinch: the general principal is applicable anywhere, but as axw mentioned to me, maas allows apt mirroe to be configured for it so juju could make special use of that to set the juju apt mirror setting off of what maas uses
[03:05] <wallyworld> instead of making the user to specify manuall in 2 places
[03:05] <axw> natefinch wallyworld: I'm not sure if it does now ... it has configuration for proxies for sure
[03:06] <natefinch> wallyworld: does juju's apt mirror get propagated to containers?
[03:06] <wallyworld> natefinch: no, that's the whole point of this work :-)
[03:06] <wallyworld> it is supposed to
[03:06] <wallyworld> so we need to figure out why not and fix
[03:07] <wallyworld> that's my understanding anyway
[03:07] <natefinch> wallyworld: ok... just making sure I understand the problem correctly.  Sounds like it's two things: 1.) juju apt mirrors don't get propagated to containers. 2.) (bonus points) juju should pick up maas's apt mirror and pass it into containers juju creates on maas nodes
[03:07] <wallyworld> yes, assuming maas has such a setting
[03:07] <axw> yup
[03:07] <wallyworld> given all this, we need to audit what's there in juju already
[03:08] <wallyworld> so we understand the current actual behaviour
[03:08] <wallyworld> and figure out the gap between that and the to be
[03:08] <wallyworld> and document the to be in that spec
[03:10] <axw> wallyworld: I meant to ask, when you've got a spare few minutes, can you please have a look over my openstack PR?
[03:11] <wallyworld> sure
[03:12] <wallyworld> axw: looks like you already have a +1?
[03:13] <axw> wallyworld: yeah, but babbageclunk is not a graduated reviewer AFAIK
[03:13] <wallyworld> ah, i didn't check who did it
[03:13] <wallyworld> just saw the tick
[03:24] <mup> Bug #1334481 changed: juju should not record ssh certificates of ephemeral hosts <ci> <cloud-installer> <landscape> <juju-core:In Progress> <https://launchpad.net/bugs/1334481>
[03:27] <natefinch> where did all the help go?
[03:27] <natefinch> do we not have help on the providers in the CLI anymore?
[03:27] <wallyworld> axw: lgtm with a drive by request
[03:28] <wallyworld> natefinch: i think the help topics are under construction, not sure
[03:28] <axw> wallyworld: ta
[03:28] <natefinch> wallyworld: ok, that gives me hope.  Right now, juju bootstrap on a new cloud basically just gives me the middle finger with no way to figure out what I'm supposed to do.
[03:28] <wallyworld> what do you mean?
[03:29] <natefinch> $ juju bootstrap google google
[03:29] <natefinch> ERROR detecting credentials for "google" cloud provider: gce credentials not found
[03:30] <natefinch> and as far as I can tell, none of our help actually tells you how to enter those credentials
[03:30] <wallyworld> juju help add-credentials
[03:30] <natefinch> $ juju help add-credentials
[03:30] <natefinch> ERROR unknown command or topic for add-credentials
[03:31] <wallyworld> sorry, no s
[03:31] <wallyworld> juju help add-credential
[03:31] <natefinch> oh man... bad one to not have a plural alias
[03:31] <wallyworld> well, it is only a single credential
[03:32] <natefinch> it is very often used in the plural, though
[03:32] <wallyworld> natefinch: juju help bootstrap tells you what you need anyway
[03:32] <wallyworld> but spot the sypo
[03:32] <wallyworld> typo
[03:33] <natefinch> yeah, IWas gonna say, it even says to see "add-credentials"
[03:33] <wallyworld> so i'm not sure how the current help is deficient
[03:33] <wallyworld> bootstrap failed, juju help bootstrap has the answer
[03:33] <wallyworld> albeit with a typo
[03:34] <natefinch> juju help bootstrap is a wall of text.  it woudl be nice if the error about "credentials not found" also said "see juju help add-credential"
[03:35] <wallyworld> hopefully that stuff is being addressed
[03:35] <natefinch> I hope so :)
[03:35] <natefinch> we do still need juju help google/gce
[03:35] <wallyworld> i'm not 100% sure of the status of all that
[03:36] <natefinch> understood
[03:57] <natefinch> gah
[03:58] <natefinch> spend 15 minutes figuring out gce's credentials only to hit another bootstrap error:
[03:58] <natefinch> cannot start bootstrap instance: sending new instance request: sending new instance request: googleapi: Error 400: Invalid value for field 'resource.networkInterfaces[0].network': 'global/networks/default'. The referenced network resource cannot be found., invalid
[04:00] <menn0> davecheney: small utils/ssh change to allow StrictHostKeyChecking to be turned on: http://reviews.vapour.ws/r/4738/
[04:01] <menn0> axw: or you? ^^
[04:02] <axw> menn0: looking
[04:02] <menn0> cheers
[04:02] <natefinch> whelp, can't bootstrap gce... guess it's time to file a bug
[04:06] <axw> natefinch: :/  how are we not finding that in CI ...
[04:07] <axw> pretty sure I bootstrapped gce last week, must be something new or maybe region or account specific
[04:07] <natefinch> axw: there was some networking stuff landed today... maybe it hasn't made it through CI yet
[04:07] <axw> ah
[04:07] <natefinch> axw: or at least, I heard them talking about networking stuff... I don't know for sure if anything landed
[04:09] <natefinch> hmm.. the commit history on master does not look like anything interesting landed lately
[04:10] <natefinch> yeah, weird, even if I do it from master  weeks ago, still fails same way
[04:10] <natefinch> I must be special
[04:11] <natefinch> or I have to configure my GCE account in some way that I haven't
[04:15] <menn0> axw: thanks for the review. I think strict should be the default too but I didn't want to break existing consumers of utils/ssh
[04:15] <menn0> axw: FWIW it will soon default to on for juju ssh/scp"
[04:15] <menn0> it's working on my machine
[04:16] <menn0> pulling the host keys from the API server etc
[04:16] <menn0> but needs tidying up and better test coverage
[04:16] <axw> natefinch: did it fail for you immediately? it seems to be working for me, but hasn't finished yet
[04:16] <axw> menn0: fair enough
[04:16] <axw> menn0: cool :)
[04:17] <natefinch> axw: failed in 10 seconds
[04:17] <axw> natefinch: I guess it's something about your account/project
[04:17] <natefinch> axw: yeah, I'll try creating a new project
[04:18] <anastasiamac_> yes, my gce is bootstrapping fine too from master tip..
[04:19] <natefinch> this was a fairly old project... I'll see if a new one works better
[04:19] <natefinch> still weird
[04:22] <natefinch> that seems to be working better.
[04:25] <davecheney> menn0: lookin
[04:25] <menn0> davecheney: it's all good. axw already reviewed.
[04:28] <mgz> axw: http://reports.vapour.ws/releases/3933 <- note gce
[05:00] <mup> Bug #1576503 opened: Agents stuck in failed state <juju-core:New> <https://launchpad.net/bugs/1576503>
[05:01] <axw> mgz: interesting, seems to be different tho
[05:06] <menn0> davecheney: screw you fslock...
[05:06] <mgz> axw: possibly over quota and bad message?
[05:07] <mgz> axw: we had passes since then
[05:08] <axw> mgz: hmm dunno, not much to go on apart from failing to get public addresses...
[05:08] <axw> sounds plausible tho
[05:09] <axw> mgz: ah yes, GCE operation error: (QUOTA_EXCEEDED) Quota 'CPUS' exceeded.  Limit: 96.0
[05:19] <mup> Bug #1576509 opened: Race in macaroon-bakery <ci> <race-condition> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1576509>
[05:19] <mup> Bug #1576510 opened: Race in macaroon-bakery <ci> <race-condition> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1576510>
[05:39] <menn0> axw: i've just realised that this SSH host key work has some interestsing corner cases with "juju scp"
[05:39] <menn0> axw: do we care much about "juju scp 0:some.file 1:"
[05:39] <menn0> ?
[05:39] <menn0> axw: it doesn't work by default because the keys aren't in place but it could
[05:40] <axw> menn0: does scp let you do that? I thought it didn't
[05:40] <menn0> axw: it definitely does... I've just been reading up on it
[05:40] <axw> so it does
[05:40] <axw> menn0: I must be living in the past
[05:40] <axw> uummm
[05:41] <axw> menn0: what do you mean "keys aren't in place"?
[05:41] <axw> why is it different to making two ssh connections, and writing to known_hosts twice?
[05:44] <menn0> axw: when you do "scp host1:some.file host2:" there's a connection from your local machine to host1, and then host1 connects to host2
[05:44] <menn0> with juju there's no keys in place to allow connections between host1 and host2
[05:44] <axw> menn0: ah, I see.
[05:44] <axw> menn0: I would say that's up to the user to manage
[05:45] <menn0> axw: that said, with "scp -3 host1:... host2:" the connections are local -> host1 and local -> host2
[05:45] <menn0> so that's more likely to work
[05:45] <menn0> except I can't make it work right now
[05:46] <axw> menn0: I don't really think it's worth worrying about
[05:46] <menn0> axw: with a bit of work I could have juju scp generate a known hosts with the keys for both hosts
[05:46] <menn0> axw: but it does make things a bit more complex
[05:47] <menn0> axw: for now I'll generate a known hosts for the first host
[05:47] <menn0> axw: that covers the majority of cases
[05:47] <axw> menn0: that will still cover "juju scp /local/file 0:remote/path" right?
[05:48] <menn0> axw: of course. "0:" would be the first (and only host) in that command line
[05:48] <axw> menn0: ok, just making sure I understood you. sounds good
[05:48] <menn0> cool
[05:49] <mup> Bug #1576503 changed: Agents stuck in failed state <juju-core:New> <https://launchpad.net/bugs/1576503>
[05:49] <wallyworld> axw: a small one for friday? http://reviews.vapour.ws/r/4739/
[05:50] <axw> wallyworld: ok
[05:52] <axw> wallyworld: how does that satisfyPrerequisites function work on ubuntu < trusty?
[05:53] <axw> wallyworld: oh, this is only for series where mongo-3.2 is available
[05:53] <axw> never mind
[05:53] <wallyworld> yeah
[05:54] <axw> separate command, was thinking it was run by the machine agent
[05:54] <axw> wallyworld: LGTM
[05:54] <wallyworld> ty
[06:15] <anastasiamac_> have u seen this before? I have just destroyed a controller (had 2 models: admin and default)...
[06:15] <anastasiamac_> when i list-controllers, i get empty list (just the headers) as expected
[06:15] <anastasiamac_> but when i list-models, i get "error: controller local.volumes not found"
[06:15] <anastasiamac_> i would have expected (and have in the past) to see empty list with just headers
[06:15] <anastasiamac_> it seems that maybe we are no longer cleaning current-controller ?.. is it bug-worthy?..
[06:22] <mup> Bug #1576527 opened: listSuite.TestListJSON got null (showSuite too) <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1576527>
[06:22] <mup> Bug #1576528 opened: current controller not cleared on destroy <juju-core:New> <https://launchpad.net/bugs/1576528>
[06:31] <mup> Bug #1576534 opened: upgrade-charm refuses to upgrade <juju-core:New> <https://launchpad.net/bugs/1576534>
[06:49] <bdx> hello everyone
[06:49] <bdx> is 'juju deploy <service> --to lxd:<machine#>' supported by the maas provider in 2.0?
[07:19] <frobware> bdx: are you talking about MAAS 2.0, or Juju 2.0?  Currently supported for Juju 2.0.  For MAAS 2.0 & Juju 2.0 currently WIP and only available behind a feature flag and building from tip....
[07:22] <bdx> frobware: nice, whats the flag?
[07:22] <bdx> frobware: maas2?
[07:23] <frobware> bdx: yep
[07:23] <bdx> frobware: I also must build master?
[07:24] <bdx> will this be dropping into beta7 then?
[07:24] <frobware> bdx: yep, and a moving target... currently very active for maas2 work
[07:24] <frobware> bdx: tbd
[07:24] <bdx> frobware: yea, I've been following along ... entirely. thx
[07:25] <frobware> bdx: we haven't done a CI run yet with this flag, so YMMV
[07:25] <bdx> I have a lab up with juju2.0 + MAAS2.0 + the flag
[07:25] <bdx> just not a build of master :-(
[07:27] <bdx> I'll give tip a build and see what gives
[07:28] <frobware> bdx: I would initially try the sinlge NIC setup, just a hint. :)
[07:29] <bdx> frobware: thanks, by single nic, you mean enlisted maas nodes only have 1 nic ?
[07:30] <frobware> bdx: yep. though things could have moved on since wed/thu when I was last tracking this.
[07:30] <bdx> that way no one has to decide what interface to put the bridge  on
[07:30] <bdx> ?
[07:31] <frobware> bdx: we bridge all interfaces now
[07:32] <frobware> bdx: I just recall see a comment from voidspace that he was trying/testing single NIC setup to begin with
[07:32] <bdx> nice, ok
[07:33] <frobware> bdx: single NIC, with multiple VLANs, all end up with their own bridge: http://pastebin.ubuntu.com/16123783/
[08:00] <rogpeppe1> anyone know why aws-china is a separate cloud rather than just an aws region ?
[08:06] <mattyw> rogpeppe1, something something firewalls I think
[08:06] <mattyw> wallyworld, you around mate?
[08:08] <voidspace> frobware: bdx: I was testing containers deployed on machines with a single nic first
[08:08] <voidspace> frobware: bdx: that worked and then we got multiple nics working too
[08:09] <frobware> voidspace: ooh nice
[08:09] <voidspace> frobware: maas2 work is now feature complete - as soon as we get it passing CI we'll remove the flag
[08:09] <voidspace> frobware: so still *technically* experimental, but hopefully not for much longer
[08:13] <anastasiamac_> rogpeppe1: different clouds for aws, aws-china and aws-gov because they require different authentication types or secret information for different regions
[08:14] <rogpeppe1> anastasiamac_: ok, so you can't use the same credentials across those clouds? that makes sense.
[08:15] <voidspace> frobware: we're still getting maas schema failures though (json doesn't match what we expect)
[08:15] <voidspace> frobware: this is the latest CI run: http://reports.vapour.ws/releases/3934/job/maas-2_0-deploy-xenial-amd64/attempt/5
[08:15] <voidspace> frobware: I'll fix that
[08:17] <anastasiamac_> rogpeppe1: essentially, yes... quoting the spec for more details :D..."There can only be one default credential for a given cloud. If that credential does not work on a particular region then you will need to specify the credential used to deploy in that region. There can only be one default region for a cloud."
[08:17] <rogpeppe1> anastasiamac_: thanks
[08:18] <anastasiamac_> rogpeppe1: i hope this helps \o/
[08:18] <anastasiamac_> rogpeppe1: there is a similar separation for azure :D
[09:01] <voidspace> frobware: standup
[09:01] <frobware> voidspace: arriving... now!
[09:06] <voidspace> frobware: babbageclunk: https://github.com/juju/gomaasapi/pull/52
[10:20] <rogpeppe1> fwereade: ping
[10:43] <Mo0O> hello
[10:54] <babbageclunk> frobware: maas is up and running, but my nodes won't pxe boot to enlist. I've turned on DHCP and downloaded a boot image. What have I missed?
[10:55] <frobware> babbageclunk: boot order on VM nodes?
[10:55] <babbageclunk> frobware: the nodes have their nics first in the boot order.
[10:55] <babbageclunk> frobware: ha ha
[10:56] <frobware> babbageclunk: images imported?
[10:56] <frobware> babbageclunk: eth0 configured to be managed (and dns and dchp)?
[10:56] <babbageclunk> yup - do I still need a 14.04 image imported?
[10:56] <frobware> babbageclunk: you have 16.04?
[10:57] <babbageclunk> frobware: yup
[10:57] <frobware> babbageclunk: what does commisionning node say in your maas settings? (the drop-down in the UI)
[10:57] <babbageclunk> frobware: xenial
[10:58] <frobware> babbageclunk: HO?
[10:58] <babbageclunk> yes
[10:59] <frobware> babbageclunk: https://plus.google.com/hangouts/_/canonical.com/juju-sapphire
[11:02] <fwereade> rogpeppe1, pong
[11:03] <rogpeppe1> fwereade: np, IS just saw an occurrence of this bug after upgrading to 1.25. fixed by a manual JS script https://bugs.launchpad.net/juju-core/+bug/1516989 (but not quite sure why the upgrade migration hadn't worked)
[11:03] <mup> Bug #1516989: juju status <service_name> broken <canonical-bootstack> <sts> <juju-core:Invalid by waigani> <juju-core 1.25:Fix Released by waigani> <juju-core (Ubuntu):Confirmed> <https://launchpad.net/bugs/1516989>
[11:04] <rogpeppe1> fwereade: so, incident fixed, but not sure why it happened.
[11:06] <fwereade> rogpeppe1, huh
[11:06] <fwereade> rogpeppe1, sorry, I have only the vaguest memories of writing that script, and I don't recall tracking the fix in 1.25
[11:07] <rogpeppe1> fwereade: np :)
[11:07] <rogpeppe1> fwereade: just thought you might be able to provide some insight at the time
[11:08] <fwereade> rogpeppe1, PR3860 went into 1.25 on dec 1, it seems -- is it remotely possible this was somehow an upgrade to an unfixed 1.25?
[11:08] <rogpeppe1> fwereade: i don't think so; let me check
[11:09] <rogpeppe1> fwereade: the version was 1.25.5
[11:09] <fwereade> rogpeppe1, yeah, that should be fine
[11:10] <fwereade> rogpeppe1, no further insights here, I'm afraid :(
[11:10] <rogpeppe1> fwereade: thanks
[11:25] <frobware> babbageclunk: if you do try my scripts you want to invoke as ... $ VIRT_RAM=1024 ./add-node ...
[11:25] <frobware> babbageclunk: because the default is 4GB, which may cause you a few problems
[11:39] <voidspace> babbageclunk: how's your branch doing?
[11:40] <babbageclunk> voidspace: finally got maas set up again, just setting up the private space node so I can have some constraints.
[11:40] <voidspace> babbageclunk: ok
[11:42] <babbageclunk> voidspace: it occurs to me I could test the change with storage constraints rather than space ones, sorry.
[11:42] <babbageclunk> voidspace: did you try adding a machine without a constraint?
[11:43] <voidspace> babbageclunk: I've added machines, yes
[11:44] <babbageclunk> voidspace: so should I just kick off the merge anyway? Not making anything worse if it doesn't work (although I think it will) and then unblocking you.
[11:44] <voidspace> babbageclunk: go for it
[11:44] <voidspace> babbageclunk: you might still need to JFDI it
[11:45] <babbageclunk> voidspace: oh, also dimiter made some comments that I should address.
[11:46] <voidspace> babbageclunk: cool
[11:47] <voidspace> babbageclunk: let me know when it's landed please
[11:50] <babbageclunk> voidspace: wilco
[11:51] <babbageclunk> voidspace: will $$jfdi$$ still run the tests?
[11:52] <frobware> babbageclunk: yes
[11:52] <voidspace> ^^^^
[11:53] <babbageclunk> voidspace, frobware: so it just bypasses blocking? Or it runs them and then merges regardless of the result?
[11:53] <voidspace> babbageclunk: bypasses blocking
[11:53] <babbageclunk> voidspace: thanks
[12:00] <babbageclunk> voidspace: building now, also successfully added a machine with a space constraint.
[12:01] <voidspace> babbageclunk: awesome!
[12:01] <voidspace> great news
[12:24] <dooferlad> frobware: could you take a look at http://reviews.vapour.ws/r/4741/ please? It is a rather important fix for the last bridge script mods.
[12:24] <frobware> dooferlad: looking
[12:25]  * dooferlad goes for lunch
[12:27]  * babbageclunk is lunching
[12:43] <frobware> dooferlad: reviewed
[12:47] <mup> Bug #1576670 opened: undefined: tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 <build> <centos> <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1576670>
[13:17] <mup> Bug #1576510 changed: Race in macaroon-bakery <ci> <race-condition> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1576510>
[13:17] <mup> Bug #1576674 opened: 2.0 beta6: only able to access LXD containers (on maas deployed host) from the maas network <oil> <juju-core:New> <https://launchpad.net/bugs/1576674>
[13:41] <mup> Bug #1576686 opened: bundle repository/bundles-lxd.yaml is invalid <juju-core:Triaged> <https://launchpad.net/bugs/1576686>
[13:43] <babbageclunk> voidspace, frobware: is there any way to get maas-cli 2 installed on wily?
[13:43] <babbageclunk> experimental3 only has xenial.
[13:43] <frobware> babbageclunk: is this because your laptop is running wily?
[13:43] <babbageclunk> frobware: yeah
[13:44] <babbageclunk> frobware: can't try to use/adapt your scripts without it
[13:53] <mup> Bug #1576695 opened: Deployer cannot talk to Juju2 (on maas2) because :tlsv1 alert protocol version <ci> <deployer> <maas-provider> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1576695>
[14:01] <dooferlad> frobware: updated http://reviews.vapour.ws/r/4741/
[14:11] <mup> Bug #1576700 opened: Misleading "Waiting for agent initialization to finish" message <ci> <status> <juju-core:New> <https://launchpad.net/bugs/1576700>
[14:11] <mup> Bug #1576704 opened: MigrationExportSuite.TestUnits unequal results <ci> <go1.6> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1576704>
[14:11] <mup> Bug #1576705 opened: cloudImageMetadataSuite.TestSaveDiffMetadataConcurrentlyAndOrderByDateCreated wrong order <ci> <go1.6> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1576705>
[14:19] <alexisb> babbageclunk, voidspace just want to make sure you guys saw this from mgz : https://bugs.launchpad.net/juju-core/+bug/1576368
[14:19] <mup> Bug #1576368: blockdevice 2.0 schema check failed: model: expected string, got nothing <ci> <deploy> <maas-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1576368>
[14:21] <babbageclunk> alexisb: yup, voidspace is on it - https://github.com/juju/gomaasapi/pull/52
[14:27] <frobware> dooferlad: it's not clear to me why we don't know all the routing information as and when we create the new stanzas and simply accumulate them. if we accumulate then it also means those bridging functions have no side effects.
[14:28] <dooferlad> frobware: the only function that has a side effect is bridge_now.
[14:29] <dooferlad> frobware: the most reliable thing to do is save routes for an interface, bridge the interface, restore routes that vanished.
[14:29] <frobware> dooferlad: iff, you first successfully write the new file
[14:30] <frobware> dooferlad: hence my preferred order. transform, successfully write new file, bridge-le-world.
[14:30] <dooferlad> frobware: you meen you want to not do anything unelss you have generated a new e/n/i?
[14:30] <dooferlad> frobware: I did just update the rev with a comment about that
[14:30] <frobware> dooferlad: it's moot. but if you can't write the file all bets sjould be off.
[14:31] <dooferlad> frobware: seems reasonable
[14:32] <dooferlad> frobware: so I just suggested not running the bridge_now loop until after the if not args.activate: ... exit(0) code
[14:32] <frobware> dooferlad: that would re-read the (new) eni file?
[14:32] <dooferlad> frobware: no
[14:32] <frobware> dooferlad: so what happesn before your exemplary if not activate?
[14:33] <dooferlad> frobware: easiest if I just write the code. Will be two minutes.
[14:33] <frobware> :)
[14:33] <alexisb> babbageclunk, voidspace awesome
[14:34] <babbageclunk> alexisb: just doing the juju diff to update the dependency now.
[14:39] <dooferlad> frobware: http://reviews.vapour.ws/r/4741/ updated
[14:45] <mup> Bug #1576728 opened: ConnectSuite.TestLocalConnectError: windows cannot connect to local lxd server <ci> <go1.6> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1576728>
[14:47] <voidspace> alexisb: we're playing whackamole with maas schema oddities :-/
[14:47] <voidspace> alexisb: we'll get there though
[14:47] <babbageclunk> voidspace, frobware: review please? http://reviews.vapour.ws/r/4742/
[14:47] <babbageclunk> voidspace: figured I'd just do this bit
[14:48] <voidspace> babbageclunk: you beat me to it!
[14:48] <babbageclunk> voidspace: :)
[14:48] <voidspace> babbageclunk: thanks, LGTM
[14:49] <alexisb> voidspace, understood, thank you for the quick turn around it makes it so the CI runs can continue to move forward
[14:49] <babbageclunk> voidspace: I'm going to quickly make a list of the attributes we use and see if roaksoax or anyone else in #maas can point out others that are optional
[14:50] <voidspace> babbageclunk: it's any that appear in the gomaasapi schema - so depending on what you mean by "we use" it's not just the ones we use
[14:51] <voidspace> babbageclunk: but yeah, catching these ahead of time would be good
[14:51] <babbageclunk> voidspace: yeah, that's what I meant - frustratingly, in some of these cases they're not even things we use
[14:52] <babbageclunk> voidspace: we're still good to JFDI things, right?
[14:53] <babbageclunk> voidspace: (optional or nullable, I guess)
[14:53] <voidspace> babbageclunk: yep
[14:53] <voidspace> babbageclunk: and yep
[14:56] <babbageclunk> voidspace: huh. Exact spelling of JFDI please?
[14:57] <mgz> I feel like our blocking process has not been working the past few weeks
[14:57] <mgz> babbageclunk: how about we just use fixes-BUGNUM instead
[14:57] <katco> ericsnow: redir: hey i'm going to miss this morning's standup... guy who is refinishing our floor just showed up
[14:58] <mgz> babbageclunk: I marked bug 1576368 blocking so don't jfdi, use magic string 'fixes-1576368'
[14:58] <mup> Bug #1576368: blockdevice 2.0 schema check failed: model: expected string, got nothing <blocker> <ci> <deploy> <maas-provider> <juju-core:Triaged by 2-xtian> <https://launchpad.net/bugs/1576368>
[14:58] <babbageclunk> mgz: Ok, thanks
[14:58] <ericsnow> katco: k, good luck
[15:10] <redir_> katco: standup?
[15:15] <redir_> katco: OK. Missed the scrollback, eric passed it on.
[15:33] <perrito666> wallyworld: still working?
[15:33] <mup> Bug #1576743 opened: juju agent 1.25.5 crashes on ubuntu 14.04 in an private openstack cloud <juju-core:New> <https://launchpad.net/bugs/1576743>
[15:33] <mup> Bug #1576750 opened: juju2 usability: many options have to be specified for every bootstrap <landscape> <juju-core:New> <https://launchpad.net/bugs/1576750>
[15:33] <mup> Bug #1576756 opened: cannot shut down controllers running other people's models <juju-core:New> <https://launchpad.net/bugs/1576756>
[15:37] <rogpeppe1> anyone know how i can "juju switch" to a different account?
[15:37] <cherylj>  rogpeppe1 you mean be a different user?
[15:37] <rogpeppe1> cherylj: yes
[15:38] <rogpeppe1> cherylj: i'm getting "ERROR getting controller environ: getting bootstrap config from API: permission denied (unauthorized access)" when i try to destroy a controller
[15:38] <rogpeppe1> cherylj: and i think the problem is probably that i'm using the wrong account
[15:38] <cherylj> there was a switch-user, I thought.   hmm  maybe that was removed
[15:39] <mup> Bug #1576756 changed: cannot shut down controllers running other people's models <juju-core:New> <https://launchpad.net/bugs/1576756>
[15:39] <rogpeppe1> cherylj: i see two users for the controller in accounts.yaml
[15:39] <rogpeppe1> cherylj: but the current user is not the admin user
[15:40] <cherylj> rogpeppe1: maybe logout / login?
[15:41] <rogpeppe1> cherylj: i don't think that's what i want
[15:41] <rogpeppe1> cherylj: looks like logout will delete my password
[15:41] <rogpeppe1> http://paste.ubuntu.com/16127920/
[15:43] <frobware> dooferlad, voidspace, babbageclunk: PTAL @ http://reviews.vapour.ws/r/4743/
[15:43] <cherylj> rogpeppe1: sounds like you want to change your password first :)
[15:43] <cherylj> I've never done that before, so I can't tell you what will happen
[15:44] <rogpeppe1> cherylj: tbh i don't want to clear the credentials from the client
[15:44] <rogpeppe1> cherylj: i ended up just manually editing the accounts.yaml file
[15:44] <cherylj> that works too
[15:44] <rogpeppe1> cherylj: thanks for the help
[15:49] <dooferlad> frobware: looking
[15:50] <dooferlad> frobware: http://reviews.vapour.ws/r/4741/ is updated again
[15:52] <dooferlad> frobware: +1
[15:55] <babbageclunk> voidspace: this is the schema as we have it now (munged for a bit more clarity): http://paste.ubuntu.com/16127709/
[15:55] <babbageclunk> roaksoax is going to get someone to go through it.
[16:05] <frobware> dooferlad: thanks. I raised the question about `ip route' and IPv6 - what happens when the iface has an IPv6 route in addition to 4?
[16:29] <frobware> cherylj: master is blocked... or not?
[16:29] <cherylj> frobware: it is blocked
[16:29] <cherylj> there are new failures
[16:30] <cherylj> and they need to be addressed
[16:30] <frobware> cherylj: ok, see you next week. :)
[16:30] <cherylj> haha
[16:30] <cherylj> frobware: it's going to be hot and humid.  Hope you're prepared
[16:31] <frobware> cherylj: it's trying to snow here... ???
[16:31] <cherylj> https://weather.com/weather/tenday/l/78757:4:US
[16:31] <frobware> ooh, some of the numbers start at 8
[16:32] <cherylj> high of 30C Friday
[16:32] <frobware> cherylj: I'll go with old money; 80 sounds way higher
[16:32] <voidspace> babbageclunk: awesome
[16:32] <voidspace> babbageclunk: nice work
[16:33] <cherylj> hehe
[16:42] <mup> Bug #1576778 opened: juju2 tab-completion for sub commands is broken in beta6 <landscape> <usability> <juju-core:New> <juju (Ubuntu):New> <https://launchpad.net/bugs/1576778>
[16:50] <alexisb> katco, ping
[16:51] <katco> alexisb: pong
[16:51] <alexisb> heya katco , we need some help unblocking master and cherylj is currently occupied with sprint tasks for next week
[16:52] <alexisb> katco, can you please rally the troupes around these 1.6 failures:
[16:52] <alexisb> https://goo.gl/0jYcTy
[16:52] <katco> alexisb: sure thing
[16:52] <alexisb> thank you, I am here if you have qs
[16:52] <alexisb> though I will be changing locations here in a minute
[16:52] <katco> alexisb: thanks
[16:54] <katco> alexisb: for bug 1576670. what substrates are still on 1.2? i thought we had 1.6 backported to trusty and we were now fully on 1.6?
[16:54] <mup> Bug #1576670: undefined: tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 <blocker> <build> <centos> <ci> <go1.2> <go1.6> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1576670>
[16:54] <alexisb> 1.6
[16:54] <alexisb> no more 1.2
[16:54] <cherylj> katco: that bug started the discussion this morning
[16:55] <cherylj> of whether or not we still use go 1.2 for our windows / centos unit tests
[16:55] <cherylj> because those unit tests fail under go 1.6
[16:55] <katco> cherylj: if we do, that's a bug against CI i think? windows can use 1.6 without any problem. centos i'm less sure of. what do you think?
[16:55] <cherylj> so if we can get the windows / centos tests working with go 1.6, that bug will be invalid
[16:55] <mgz> katco: 'without any problem' is the issue
[16:55] <cherylj> yeah
[16:56] <katco> cherylj: mgz: ah i see... chicken and egg problem? there are some centos/windows tests failing on 1.6?
[16:56] <cherylj> katco: exactly :)
[16:56] <cherylj> so we're asking for help to fix those other tests
[16:56] <alexisb> 1.6 all the way!
[16:56] <katco> cherylj: read my mind: i think we should push forward. mark bug 1576670 as invalid and flag failing tests as blockers
[16:57] <mup> Bug #1576670: undefined: tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 <blocker> <build> <centos> <ci> <go1.2> <go1.6> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1576670>
[16:57] <mgz> 200% compile time slowdowns all the way!
[16:57] <cherylj> huzzah!
[16:57] <katco> mgz: that has been addressed in tip :)
[16:57] <katco> cherylj: so are you fine with me marking this as invalid? can you raise the other test failures as blocking bugs?
[16:58] <cherylj> katco: already did
[16:58] <cherylj> :)
[16:58] <katco> cherylj: ty kindly :)
[16:58] <alexisb> katco, what we need from the core team is to fix the test failures
[16:58] <katco> alexisb: agreed
[16:58] <mgz> katco: yeah, it's now just a 100% slowdown
[16:59] <katco> mgz: native go compiler > c compiler, and slowdowns will be addressed over time :) it's a good thing overall!
[16:59] <katco> ericsnow: redir: redir_: what are you 2 up to?
[16:59] <katco> perrito666: what are you working on?
[16:59] <mgz> katco: I'm not being too serious :)
[16:59] <cherylj> okay, I'm going to get some lunch.  bbiab
[17:00] <ericsnow> katco: syslog
[17:00] <katco> ericsnow: the 1-pager?
[17:00] <alexisb> folks these blockers are top priority so if you have a nice stopping point
[17:00] <ericsnow> katco: yep
[17:00] <redir> katco: The LTS update fix and ian's feedback.
[17:00] <katco> ericsnow: sounds like that's getting trumped
[17:00] <katco> redir: k, carry on
[17:00]  * redir nods
[17:01] <katco> redir: hi btw
[17:01] <redir> morning katco :)
[17:01]  * alexisb changes locations brb
[17:01] <katco> ericsnow: you have your pick:
[17:01] <katco> https://bugs.launchpad.net/juju-core/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.st
[17:01]  * katco now understands why alexisb put that in a url shortener
[17:02] <ericsnow> katco: k
[17:02] <katco> ericsnow: lmk which one you pick up so i can pick something else
[17:04] <ericsnow> katco: it'll be a few minutes before I can get to a stopping point
[17:04] <katco> ericsnow: np at all, same here
[17:12] <mup> Bug #1576670 changed: undefined: tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 <blocker> <build> <centos> <ci> <go1.2> <go1.6> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1576670>
[18:03] <mup> Bug #1576778 changed: juju2 tab-completion for sub commands is broken in beta6 <landscape> <usability> <juju-core:New> <juju (Ubuntu):New> <https://launchpad.net/bugs/1576778>
[18:03] <mup> Bug #1576318 opened: juju register not clear that you're creating a new password <apport-bug> <i386> <usability> <xenial> <juju-core:Triaged> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1576318>
[18:03] <mup> Bug #1576805 opened: Juju controllers set the rsyslog NetstreamDriver affecting all subsequent rsyslog configuration <juju-core:New> <https://launchpad.net/bugs/1576805>
[18:35] <katco> cherylj: hey, build bot is wrong? https://github.com/juju/juju/pull/5318
[18:36]  * cherylj looks
[18:36] <mgz> katco: it's being fussy about high vs critical
[18:36] <katco> mgz: ah ok. jfdi?
[18:36] <mgz> go again, I edited the bug
[18:36] <katco> mgz: ta
[18:36] <mgz> use $$fixes-NNN$$
[19:22] <katco> mgz: sanity check: for bug 1576728, i'm just not going to run any tests for lxd on windows
[19:22] <mup> Bug #1576728: ConnectSuite.TestLocalConnectError: windows cannot connect to local lxd server <blocker> <ci> <go1.6> <regression> <test-failure> <unit-tests> <windows> <juju-core:In Progress by cox-katherine-e> <https://launchpad.net/bugs/1576728>
[19:22] <katco> cherylj: ^^
[19:23] <cherylj> katco: sounds good.  You may also need to include a skip for centos too
[19:23] <cherylj> so, I guess if ! ubuntu
[19:23] <katco> mgz: cherylj: when/if lxd is supported on windows, this code will have to be modified to be platform independent anyway. the error instructions don't make sense for anything but ubuntu
[19:24] <katco> cherylj: yeah good point
[19:24] <mgz> katco: I'm not sure on that,
[19:24] <mgz> we have some general isolation test failures with lxd
[19:24] <cherylj> but yeah, we'd want to move to a mocked out lxd client
[19:24] <katco> mgz: i don't follow
[19:25] <katco> cherylj: not only that, but these tests would be testing code that would never be exercised on those platforms
[19:25] <cherylj> that's true
[19:26] <mgz> katco: I've not looked in detail, but we have a bunch of tests that aren't very unity and actually try to talk to the local lxd
[19:26] <mgz> which should really just not do that at all, rather than be skipped on some platforms
[19:26] <katco> mgz: oh, yes. i completely agree there. just trying to remove the blocker pedantically
[19:26] <katco> mgz: not really prepared to do major surgery atm :)
[19:27] <mgz> katco: eg bug 1564511 - which is a different suite
[19:27] <mup> Bug #1564511: cmd/jujud/reboot tests fail with lxd container running <ci> <regression> <s390x> <tech-debt> <test-failure> <unit-tests> <xenial> <juju-core:Triaged> <https://launchpad.net/bugs/1564511>
[19:27] <katco> mgz: yeah. that's just so awful.
[19:27] <mgz> so, I'm not anti skipping on windows where the test otherwise makes sense but isn't code we ever run on windows
[19:28] <katco> mgz: i'll lay down robustness in layers. i'll address platform robustness in this patch
[20:27] <redir> katco: ericsnow got a minute to help me understan PatchValue?
[20:28] <ericsnow> redir: sure
[20:28] <katco> redir: sure, moonstone?
[20:28] <redir> sure
[20:33] <ericsnow> mgz: do you know of any problems we have had (testing or otherwise) due to Windows's long clock tick (15.6 ms by default)?
[20:33] <mup> Bug #1571783 changed: Windows unit tests cannot setup under go 1.6 <ci> <go1.6> <jujuqa> <regression> <test-failure> <unit-tests> <windows> <juju-core:Fix Released by hduran-8> <https://launchpad.net/bugs/1571783>
[20:36] <mgz> ericsnow: not with juju I think
[20:36] <ericsnow> mgz: k
[20:37] <ericsnow> mgz: I'm thinking that the bug I'm working on may be due to that long clock tick
[20:40] <mgz> ericsnow: it's possible, given we have a number of rather timing dependent tests
[20:43] <mup> Bug #1576851 opened: juju debug-log -i unit-rabbitmq-server-0 is unfriendly <juju-core:New> <https://launchpad.net/bugs/1576851>
[21:32] <alexisb> anastasiamac, are you there
[21:32] <anastasiamac> alexisb: i am
[21:33] <alexisb> heya
[21:33] <anastasiamac> alexisb: do u have a sec?
[21:33] <alexisb> I do
[21:33] <anastasiamac> could we go to our 1:1?
[21:33] <alexisb> yep
[22:19] <mup> Bug #1576873 opened: Juju2 cannot deploy centos or windows workloads on maas 1.9 <blocker> <centos> <ci> <maas-provider> <regression> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1576873>
[22:19] <mup> Bug #1576874 opened: restore-backup never completes <backup-restore> <blocker> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1576874>
[22:28] <perrito666> alexisb: still here?
[22:29] <redir> thanks katco ericsnow that was very useful
[22:29] <alexisb> perrito666, yes
[22:29] <alexisb> wuz up?
[22:29] <perrito666> alexisb: priv
[22:29] <katco> redir: np
[22:45] <ericsnow> katco: you have a sec for a quick review?  http://reviews.vapour.ws/r/4746/
[22:45] <katco> ericsnow: sure tal
[22:46] <katco> ericsnow: do we have a way to test this empirically?
[22:46] <ericsnow> katco: test what exactly?
[22:46] <katco> ericsnow: that the fix for your bug works
[22:47] <ericsnow> katco: I suppose I could spin up my KVM, update it, etc. and then run that test and hope my local timing isn't slow anyway...
[22:48] <ericsnow> katco: but running in KVM might mask the issue
[22:48] <ericsnow> probably
[22:48] <katco> ericsnow: i think it'd be enough to land the fix and coordinate with ci folks
[22:48] <katco> ericsnow: to ensure it's really solved
[22:49] <ericsnow> katco: that's what I was thinking
[22:49] <katco> ericsnow: shipit
[22:49] <ericsnow> katco: thanks
[22:52] <ericsnow> mgz: are all the go-1.6, windows blocks supposed to be critical?
[22:52] <ericsnow> mgz: trying to merge a fix
[22:52] <katco> ericsnow: flag your bug as critical to get it through
[22:53] <ericsnow> katco: done
[23:23] <perrito666> :950
[23:23] <perrito666> meh, wrong window


[19:01] <OverCoder> Hello everyone
[19:01] <OverCoder> I am maintaining a PPA for HexChat
[19:01] <OverCoder> and I have these dependencies defined in my debian/control
[19:02] <OverCoder> https://qbin.io/ep6yl74nh
[19:02] <OverCoder> When users are installing hexchat, libluajit stuff aren't getting installed
[19:02] <OverCoder> What could it be?
[20:29] <teward> OverCoder: if it needs it as a runtime dependency you need to add it to Depends, not build-depends
[20:29] <teward> OverCoder: libluajit doesn't add any *runtime* dependencies
[20:29] <teward> it only adds build depends
[20:29] <teward> if it needs to be a runtime dependency it should be added to the package Depends: line, not the Build-Depends (though it'd probably need both)
[21:01] <OverCoder> teward, all fixed, thanks
[21:03] <teward> OverCoder: you're most welcome :)
[21:03] <OverCoder> <3


[00:27] <bkerensa> pleia2: Oh ok
[00:27] <bkerensa> pleia2: One blurb or three blurbs?
[00:34] <akgraner> pleia2, thanks!
[00:36] <bkerensa> pleia2: Ok I think I got all three blurbs in there :) I gotta run to dinner now.... I didn't even know I had xchat connected to znc
[01:27] <pleia2> bkerensa: I was actually looking for just one summary so we don't take up *too* much space for a single event, like I did one summary for both about the UK party
[01:28] <pleia2> I can take what you have an condense it though, thank you :)
[01:29] <bkerensa> pleia2: Ahh you sure I can condense... I actually decided to skip going out to dinner (its 29 degrees outside)
[01:29] <bkerensa> Penguin weather up here
[01:34] <pleia2> it's been more chilly than usual here, 40s in the evenings!
[01:34] <pleia2> 50 right now
[01:50] <bkerensa> Yeah.... We have two heaters running full clock which kept us toasty last winter but there is still a lingering chill
[01:51] <bkerensa> So much for no such thing as climate change
[03:20] <Pendulum> pleia2: you haven't told your Maine relatives about the "chilly" evenings of the 40s, right? ;-)
[04:42] <pleia2> Pendulum: only my sister, who now lives in alberta and laughed at my thoroughly :)
[04:43] <pleia2> s/my/me
[17:11] <akgraner> pleia2, I'll send some time tonight writing as many summaries as possible
[17:11] <akgraner> spend
[17:12] <akgraner> 3 hours of quiet time once Pete leaves for Boston - he was home a whole 35 hours this time :-)
[17:13] <pleia2> aw, only 35 hours!
[17:13] <pleia2> thanks :)
[17:13] <pleia2> anyone else available for summaries today? https://docs.google.com/Doc?docid=0AdKZelXU8Y2LZGNrcHRkYmhfODlkODNxNnRnZA&hl=en
[17:14] <pleia2> haven't seen MrChrisDruif these past couple days
[18:24] <MrChrisDruif> Evening everyone
[18:25] <holstein> MrChrisDruif: o/
[18:26] <MrChrisDruif> holstein, \o
[18:27] <Unit193> Speak of the devil...
[18:28] <holstein> w0w
[18:28] <holstein> thats s good chunk of it done!
[18:28] <MrChrisDruif> I'd rather not. But what is the link to the google docs again
[18:28] <MrChrisDruif> ?
[18:28] <holstein> im done for the day
[18:28] <holstein> https://docs.google.com/document/edit?id=18ZbtFHQq6uMj7iuRLd11VH8V5Uc_FA0IfgiRUcbMbQk
[18:29] <MrChrisDruif> Maybe I can make a bit.ly link for it so the pad.ubuntu-uk.org can be replaced with it?
[18:30] <holstein> ask the boss...
[18:30] <holstein> i agree it could be more memorable
[18:30] <holstein> its stuck in my google docs list of i would never find it
[18:30] <MrChrisDruif> akgraner, your input please?
[18:32] <pleia2> we're not using the pad.ubuuntu-uk.org because it's too unreliable
[18:33] <MrChrisDruif> pleia2, I wasn't asking why we weren't using it but why were still lining to it =)
[18:33] <MrChrisDruif> Linking*
[18:34] <pleia2> because we've been too busy working on the newsletter to do a thorough review of the wiki pages to update them
[18:34] <pleia2> akgraner is planning on working on it over the holidays
[18:34] <pleia2> there is a lot of outdated stuff on the wiki :(
[18:35] <MrChrisDruif> pleia2, I was referring to the channels topic
[18:36] <pleia2> ah, that too :) it hasn't been updated since June
[18:37] <pleia2> there :)
[18:37] <holstein> OH... make a bitly and put it in the topic... i like that
[18:38] <pleia2> maybe a bitly of the google doc, since we actually use that?
[18:39] <pleia2> there
[18:39] <MrChrisDruif> That's what I meant, thank you =)
[18:44] <holstein> :)
[18:59] <MrChrisDruif> Didn't do me much good thou. Can't seem to edit on my mobile for now
[19:04] <MrChrisDruif> Can someone add this link to the Ubuntu Studio meeting minutes on the docs?
[19:04] <MrChrisDruif> https://wiki.ubuntu.com/UbuntuStudio/Meetings/2011December11
[19:05] <pleia2> done
[19:20] <MrChrisDruif> Thans pleia2


[03:30] <ianto> Espreon: Sori! wi wedi bod yn yfed
[04:05] <Espreon> It's nothing to worry about.
[04:09] <ianto> Espreon: WRecked!
[04:09] <Espreon> Oh, now you're sounding like me!
[04:10] <ianto> Thanks!
[04:11] <Espreon> You're quite welcome, good sir.
[04:11] <Espreon> Now, let's hope this giant poison oak bubble on my foot magickally disappears soon.
[04:12] <Espreon> Is there poison oak in the isles?
[04:12] <ianto> I don't think si
[04:12] <ianto> *so
[04:13] <Espreon> How 'bout poison ivy?
[04:13] <ianto> Maybe, dunno!
[04:13] <Espreon> Let's hope not!
[04:14] <Espreon> 'Cause these are evil plants...
[04:19] <Espreon> Well, I think I'll get off the Internet now. Nos da is it?
[04:20] <Espreon> Apparently it is.
[04:21] <Espreon> And apparently it means the same thing in Cornish...
[04:21] <Espreon> ... according to good ol' Wiktionary.
[04:21] <Espreon> OK, I'm gone now.


[11:03] <dbarth_> klattimer: ping? around?
[11:03] <klattimer> here
[11:03] <dbarth_> hi Karl
[11:04] <klattimer> sup?
[11:04] <dbarth_> i know you've just discussed with Neil but what's the plan with the im issues
[11:04] <dbarth_> afaict, mutter can't be fixed easily, right
[11:05] <klattimer> there's a potential problem with the displaying of the suggestions list and/or the language bar
[11:05] <dbarth_> still, with the fix you made for the ibus indicator, that can at least help people using an im context, except for the search box, right?
[11:05] <klattimer> yep
[11:05] <klattimer> that should work perfectly
[11:05] <dbarth_> klattimer: have you subtmitted that for review yet? is there something i need to do to have that go into the sru process?
[11:11] <klattimer> I've poked didrocks and kenvandine about it seb also poked didrocks
[11:11] <klattimer> my branch is chewed up a little bit
[11:11] <didrocks> the patch doesn't apply when I tested it
[11:12] <klattimer> but kenvandine should be able to take the two patches I have
[11:12] <klattimer> I fixed it yesterday in my branch
[11:12] <klattimer> I had to split two patches up
[11:12] <klattimer> kenvandine was working slightly differently to me
[11:13] <didrocks> ok, I'm wanting for something from kenvandine then
[11:14] <klattimer> the patches 03 and 05 here are the ones which work for me
[11:14] <klattimer> http://bazaar.launchpad.net/~karl-qdh/ubuntu/maverick/ibus/ibus-indicator/files/head:/debian/patches/
[11:14] <klattimer> but obviously both need updating in the package
[11:20] <dbarth_> klattimer: ok, i'll put that in an email to ken and you
[11:21] <klattimer> cool
[11:21] <klattimer> ken already knows
[11:25] <dbarth_> klattimer: ok done, yes, it's just to let him know also that there is an oem tag on the bug as well
[11:25] <klattimer> oh cool
[11:26] <klattimer> I was thinking about making a package for the "flag" icons I did
[11:26] <dbarth_> for the mutter version so it seems its toasted; try to get back to me (and njpatel now) on what you recommend to get that working on compiz
[11:26] <klattimer> and have the package set the gconf key on/off on install/removal
[11:26] <dbarth_> whereas the icons are in the same package atm?
[11:26] <klattimer> compiz will be a deeper investigation
[11:27] <dbarth_> i think that's better for an sru, since it doesn't change the pakcaging
[11:27] <klattimer> well, the icons don't exist in any package right now
[11:27] <dbarth_> however, for natty, that may be interesting; i don't know what packagers prefer
[11:27] <dbarth_> yeah but i mean, preserve the dependency tree, without a new dep
[11:27] <klattimer> well there'd be no new dep
[11:28] <klattimer> just an optional package the way I was thinking
[11:28] <klattimer> well, to release to my ppa for during the maverick cycle
[11:28] <klattimer> we work out what to do next sometime this cycle
[13:45] <kenvandine> klattimer, i should just be able to merge your packaging branch right?
[13:51] <kenvandine> ok... trying to build after merging the branch fails to apply the patches...
[13:51]  * kenvandine tries to just pick the patches out... something is hosed here
[13:53] <didrocks> kenvandine: that's what I told yesterday :)
[13:54] <kenvandine> i hit this at UDS too... but the patch at that time didn't seem to fix the bug for me anyway
[13:54]  * kenvandine gets the package in shape again
[13:57] <kenvandine> klattimer, should i add the 07_disable_introspection.patch patch too?
[14:04] <kenvandine> ok, just grabbing the patches and adding them to a pristine branch seems to work... now to test it :)
[14:04] <kenvandine> klattimer, what is the deal with the 07_disable_introspection.patch, does that fix a bug?
[14:05] <kenvandine> should that be going in as an SRU?
[14:33] <kenvandine> klattimer, ping
[14:33] <kenvandine> i have it working
[14:33] <kenvandine> huge improvement over before... and the package is fixed
[14:33] <kenvandine> but there is still a "quirk"
[14:33] <kenvandine> if i have 2 input methods
[14:33] <kenvandine> and i select one
[14:34] <kenvandine> i can't switch to the other without hitting restart
[14:34] <kenvandine> but... if i restart i can switch it
[14:34] <kenvandine> and cpu load is fine
[14:34] <kenvandine> so a HUGE improvement :)
[14:38] <kenvandine> actually, i am only seeing that behavior in my VM
[14:38] <kenvandine> i can change input methods fine on my laptop
[15:08] <kenvandine> didrocks, seb128, dbarth_, klattimer: ibus uploaded, i'll talk to pitti about getting it approved
[15:09] <didrocks> kenvandine: nice!
[15:09] <kenvandine> there was a bunch of already applied patches in the bzr branch
[17:28] <klattimer> kenvandine: yeah, I found that in my clone branch too and tried to unpick them
[17:37] <kenvandine> i didn't upload it with the introspection patch
[17:38] <kenvandine> locally i couldn't build it without that patch... but in pbuilder it was fine
[17:38] <kenvandine> klattimer, ^^
[17:38] <klattimer> kenvandine: yeah a useful patch I found but non-essential in theory
[17:39] <kenvandine> i wish i knew what caused that
[17:39] <kenvandine> i can't build dbusmenu locally either
[17:39] <kenvandine> but i can in pbuilder
[17:39] <klattimer> gi has changed in the repos I think
[17:39] <kenvandine> g-ir-scanner blows up
[17:39] <kenvandine> well something is broken in one of my installed packages
[17:39] <kenvandine> i just can't track it down
[17:39] <kenvandine> a pristine chroot is fine though


[11:15] <sidi> Just got Unable to negotiate with <IP_ADDRESS>: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1 when trying to push to my LP repo (just updated my SSH client). Are there any plans to move on to more secure cyphers?
[12:36] <cjwatson> sidi: Yes, I've been working on it on and off, but it's requiring development work in Twisted
[12:36] <cjwatson> Since we use a rather custom SSH server, so it's not just a matter of upgrading OpenSSH or whatever
[12:41] <sidi> cjwatson, fair enough :-)


[08:34] <LocutusOfBorg> hello apw, do you mind merging this? https://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/?id=bcdf0a6d1924367b99cf5c30b5f0e8f9bd0cb079
[08:34] <LocutusOfBorg> background story: LP: #1669807
[08:35] <apw> LocutusOfBorg, will the next update to the dkms package contain that too ?
[08:39] <apw> LocutusOfBorg, oh it already does, so you want that resync'd ... ok
[08:57] <LocutusOfBorg> yeah


[00:16] <knome> slickymaster, the "wiki" team is basically people in the doc team anyway
[00:17] <slickymaster> knome,  are you referring to the editors?
[00:18] <knome> slickymaster, referring to the #ubuntu-wiki discussion
[00:20] <slickymaster> I saw the mail on the DocumentationTemplate, but assumed that was meant just for the wiki editors and admins
[00:20] <knome> that's a different discussion :)
[00:20] <knome> but it was meant for everybody editing the wiki
[00:21] <knome> because the templates are for everybody to use
[00:21] <slickymaster> yes,
[00:22] <knome> my comment was pointed at https://lists.ubuntu.com/archives/ubuntu-doc/2014-January/018548.html
[00:23] <slickymaster> ah :)
[00:24] <slickymaster> knome, but I remember talking with elfy about it and I got the impression that was composed mostly by ubuntu forum mods and some contributors
[00:25] <knome> it's possible it used to, though ultimately the team is/should be just a (non-separate) subteam of the docs team
[00:25] <knome> consisting of everybody who is interested in the wiki
[00:26] <slickymaster> yes and that is logical
[00:26] <slickymaster> but it's been on stand by for while
[00:30] <knome> it's been active lately ;)
[00:32] <slickymaster> well, keeping in mind the idea of people in the doc team, yes, you're right
[00:33] <knome> too much team structure is bleh anyway
[00:33] <slickymaster> knome, but I got to say that the initial idea of migrating some threads from the forum to the wiki strikes me as really good
[00:33] <belkinsa> Hey all, what's up?
[00:33] <knome> yep, i guess that makes them more discoverable
[00:34] <slickymaster> hi belkinsa, how were your holidays
[00:34] <slickymaster> ?
[00:34] <belkinsa> There were fine, yours?
[00:35] <slickymaster> kind pf bumpy, but with health, thanks
[00:48] <belkinsa> Not a problem.  And I know what you mean, I had a nasty burn out
[00:48] <knome> i'm off, have fun belkinsa
[00:48] <belkinsa> See you.
[00:49] <slickymaster> I'm off to belkinsa
[00:49] <slickymaster> cy tomorrow
[00:49] <belkinsa> See you too
[00:49] <belkinsa> Yup
[11:11] <slickymaster> knome: ping
[12:39] <knome> slickymaster, pong
[13:55] <SaberX01> GM all .. after pulling the ubuntu-doc branch yesterday , I tied to use make status  and it's falling over, I can post the actual error if need be, but is this still used?
[13:56] <SaberX01> I played around with different Grep one liners and got a list, but would nice to see the html out from make.
[13:57] <SaberX01> like: grep -R 'status="review"/>' ./   and jsut change the review to help or whatever, then I used |wc -l to get a count on what was what on the status indicators.
[15:09] <slickymaster> knome: you there?
[20:36] <SaberX01_> Is this the best place to discuss ubuntu-docs or is it better to go though the mailing lists?
[21:00] <shaunm> SaberX01_: probably ok to ask things here, but if you don't get a response, use the list
[21:01] <SaberX01_> Ok, thanks, just had probelm with  .. make status .. not working
[21:02] <shaunm> in the ubuntu-docs repository? I don't even see a status target in the Makefile
[21:05] <SaberX01_> I was able to build all the files, but when reading through the editing / checking dos online, said to use make status to list the files current status, help, review  etc
[21:06] <shaunm> that might be outdated info. where's that page?
[21:07] <SaberX01_> Let me get it, net really slow at the moment.
[21:09] <SaberX01_> shaunm, Bottom of this page: https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation/Checking
[21:10] <SaberX01_> the Tags are there cuz I can grep the tag status with: grep -R 'status="review"/>' ./
[21:14] <shaunm> SaberX01_: which document are you looking at?
[21:14] <SaberX01_> This one: https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation/Checking
[21:15] <shaunm> no, I mean on which document are you trying to run make status?
[21:15] <shaunm> the ubuntu-help document in the ubuntu-docs repository?
[21:16] <shaunm> this wiki page is all about docbook, and I think it's probably outdated (though maybe it's correct for some other document)
[21:16] <SaberX01_> Oh, I'm not marking them up, was just looking for the files that had a status of "help" on them .. to see if there was any I could help out with. But with 370+ files, that's allot to look through for jsut the "help-wanted" files.
[21:17] <SaberX01_> shaunm, Yes, this is system Documentation: lp:ubuntu-doc
[21:17] <SaberX01_> I pulled the Repo .. and was lookign to start helping with it, reviewing, maybe a few edites etc.
[21:18] <shaunm> you should probably just use the yelp-check command, from the yelp-tools package
[21:19] <SaberX01_> ok .. I'm kinda new to the system docs stuff, so, I need to go read up on yelp-tools not used them before.
[21:19] <SaberX01_> Is the Ubuntu dosumentation Page out of date then / needs updating ?
[21:21] <shaunm> I can't really say for certain. the team maintains a few different documents, and that info might still be correct for some of them
[21:21] <shaunm> (though in that case it should probably say so)
[21:21] <shaunm> I just know mallard and upstream yelp stuff
[21:22] <SaberX01_> ok, Im looking at yelp-tools now, did not see anything on the wiki about the tools. Mainly Im looking to spend calories, but where is the big sea of documents is the question :-)
[21:23] <SaberX01_> shaunm, I just wanted to work on the 14.04 docs and thought I was following the right How-Too there.
[21:24] <shaunm> somewhat useful: https://wiki.gnome.org/Apps/Yelp/Tools/yelp-check
[21:25] <SaberX01_> ok, and 14.04 is all Mallard now yes?
[21:32] <dsmythies> SaberX01_: I don't know about "make status", as I never use it. In the last cycle I didn't even know we were supposed to keep the status lines up to date.
[21:32] <dsmythies> Why? becuase I came from the server guide and we don't worry about it there.
[21:32] <dsmythies> We track status on a google page, I'll find the link in a minute...
[21:33] <SaberX01_> yelp-check status does what I was after ..
[21:33] <dsmythies> as for creating the html, please see the build wiki page. Link coming in a moment.
[21:34] <dsmythies> Oh, and "Little Girl" was working on mkaing all the status pages up to date for the 14.04 cycle a month or two ago, but I forget how far she got.
[21:34] <SaberX01_> dsmythies, Yeah, I got all fo the pages to build just fine, but was looking for pages to review, check or whatever, and had no idea where to start looking, so went to the wiki and found that .. make status ..
[21:35] <dsmythies> Give me a moment to find the links.
[21:35] <SaberX01_> dsmythies, I read a bit of what Little Girl put out, they using the Kubuntu Wiki Tasks for tracking.
[21:36] <SaberX01_> at least for Kubuntu Sys Docs anyway.
[21:38] <dsmythies> We are using this: https://docs.google.com/spreadsheet/ccc?key=0AsSw0cKYcffNdFlFakF5M0VjR002UEVvakVPZGpydHc
[21:39] <dsmythies> for status tracking for 14.04
[21:40] <dsmythies> for html see: https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation/BuildingDocumentation
[21:40] <SaberX01_> Who maintains the Spreadsheer?
[21:40] <SaberX01_> Spreadsheet
[21:41] <dsmythies> or even easier (for just english), see the build html area of: https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation/UbuntuDesktopGuide
[21:41] <dsmythies> We all maintain the spreadsheet
[21:43] <SaberX01_> I'm not on the Commit list so, just needed to figure out a work-flow and where to start. The Yelp-Tools, if folks use the Status could be really helpful.
[21:46] <SaberX01_> In any case, thanks for all the Info .. can start looking through things a bit further now.
[21:52] <dsmythies> SaberX01_: We specially did the getting started page last cycle (previous link) to, hopefully, help people get going. There is also a serverguide version.
[21:54] <dsmythies> at: https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation/UbuntuServerGuide
[21:54] <SaberX01_> Yes, I started on the server guide first, as Im more of a command-line user than desktop. went thought the mailing list, seems there making some changes there as well.
[21:55] <slickymaster> knome, there's no need now. it was related with https://help.ubuntu.com/community/HybridGraphics and https://wiki.ubuntu.com/X/Config/HybridGraphics
[21:56] <belkinsa> SaberX01_, welcome to the team, if you are new.
[21:57] <knome> aha, oki
[21:58] <slickymaster> knome, if I understood you correctly you're suggesting to merge the wiki page onto the documentation page, right?
[21:58] <knome> no... i think the wiki.u.c page has its own merits as it is
[21:58] <SaberX01_> belkinsa, thnx .. just getting a feel for things at the moment .. hope to be able to help out somewhere.
[21:59] <knome> whether some of it should be moved to the community help wiki...
[21:59] <belkinsa> Not a problem.  Make sure you join the list and introduce yourself.
[21:59] <slickymaster> knome, are you think of placing a redirect link on it?
[21:59] <knome> probably, but i'm pretty sure somebody wants to track/update exactly only what is on w.u.c
[21:59] <knome> i was thinking just a normal link would probably do
[22:00] <knome> if the content of the community help page seems to be in conflict with the w.u.c page, then that should be updated
[22:00] <slickymaster> knome, that's my opinion also. That's the reason I pinged earlier this morning.
[22:00] <shaunm> using mallard revision tags and yelp-check is really powerful
[22:00] <slickymaster> knome, I'll reply my opinion in both mailing lists
[22:00] <shaunm> but I'm extremely biased on that subject, so take what I say with a grain of salt
[22:01] <knome> slickymaster, also looking at the background, seems like https://wiki.ubuntu.com/X/Config/HybridGraphics is used by the developers to track their work
[22:01] <knome> slickymaster, so that's why i don't think we should poke that too much, or move it
[22:02] <slickymaster> agreed
[22:02] <knome> slickymaster, and copying that content over as it is... well if it changes, somebody has to make sure the content is up-to-date, and i don't want that kind of double maintaining effort
[22:03] <slickymaster> that's also why I think that the link should be the best move here
[22:03] <knome> exactly.
[22:05] <SaberX01_> shaunm, I know Im new here, but a quick grep and pipe with yelp-tools status, and bingo, had a status list.
[22:06] <dsmythies> SaberX01_: The google spread sheet is the master list, regardless of other info.
[22:07] <SaberX01_> dsmythies, ok
[22:08] <dsmythies> ... At least that is my understanding. (And as mentioned, I wasn't even updating the status lines last cycle.)
[22:10] <SaberX01_> how often are commits made ?
[22:11] <dsmythies> Commits are done as often as required. Anywhere from many per day, to none for many weeks.
[22:12] <SaberX01_> I see, and for those of us that are not on the commiters list, we send the changes to the mailing list?
[22:16] <dsmythies> You can (send to mailing list), but myself I hate that method, because it just tosses the burden to someone else. You should submit a merge proposal, as described in the getting started page (link(s) from earlier)
[22:19] <SaberX01_> Ahh, yes, thats a much better way .. thnx
[22:22] <dsmythies> SaberX01_: Are you on the ubuntu-doc mailing list? (Myself, I am somewhat IRC challenged and rarely on IRC)
[22:24] <SaberX01_> dsmythies, yes, Im on the mailing list. Have not sent out any mails yet. But it's using my Launchpad account KI7MT
[22:25] <SaberX01_> I should just use the one account KI7MT, that's where all my Ubuntu stuff is anyway.
[22:26] <SaberX01_> or nick I should say .. I do not have any accounts with SaberX01
[22:26] <SaberX01_> be back in a few.
[22:28] <belkinsa> SaberX01_, beaware that you could start another one of these months of a flood of e-mails from on list just like I did a few months back.
[22:30] <SaberX01_> belkinsa, I've been reading all of the November list mails. Allot of interesting things posted. I tried to follow the Server Guys Proposals, but I kinda got lots of the 7-To Do List :-)
[22:30] <belkinsa> Cool.  I'm more of a wiki person, so there's some e-mails that I have ignored.
[22:31] <belkinsa> We will get a prefix system going soon.
[22:32] <KI7MT> belkinsa, Im back, prefix system for what?
[22:32] <belkinsa> Hold on, lookinbg for that message
[22:32] <dsmythies> I still have not caught up on the flurry of e-mail from dec 6th tti dec 16th
[22:33] <dsmythies> I still have not caught up on the flurry of e-mail from dec 6th to dec 16th
[22:33] <belkinsa> https://lists.ubuntu.com/archives/ubuntu-doc/2014-January/018546.html
[22:33] <belkinsa> KI7MT, ^^^
[22:34] <KI7MT> may as well add [ ask ] and [ help ] :-) ... I was gonna ask about all those also :-)
[22:34] <belkinsa> Also, there is one e-mail that I didn't mean to send to the list.
[22:34] <belkinsa> Yeah, those maybe needed and go ahead.
[22:35] <KI7MT> I would think, as a minimum, [ server ] & [ desktop ]
[22:35] <belkinsa> And [wiki]
[22:36] <KI7MT> I dont have a clear understanding of the differences between wiki and help
[22:37] <dsmythies> shaunm, are you still here?
[22:37] <belkinsa> What was the help prefix for, in your mind?
[22:37] <KI7MT> I was referring to wiki.ubuntu.com and help.ubuntu.com
[22:38] <KI7MT> and what the intended use / purpose was / is.
[22:38] <belkinsa> Oh.  Help is what we work on and the wiki is for teams to use.  This is where your LoCo team stuff is.
[22:38] <belkinsa> Help is support
[22:38] <belkinsa> Wiki is where the doc team's docs are is what I meant
[22:39] <dsmythies> help.ubuntu.com is the official ubuntu documention
[22:39] <KI7MT> Ok, so the Help, in an ideal world, should follow closely with the online published Desktop & Server guides yes ?
[22:39] <belkinsa> Woah, woah!  Don't use documentation!
[22:39] <belkinsa> Use Community Help Wiki.
[22:40] <dsmythies> belkinsa, ??? help.ubutnu.com is exactly the online published Desktop & Server guides
[22:40] <belkinsa> But there is other things on that wiki also.
[22:41] <KI7MT> Here's the thing, I use this, allot: https://help.ubuntu.com/  .. both for personal and IRC support use, and often find, things need adding or updating.
[22:41] <dsmythies> And it is NOT a wiki
[22:41] <belkinsa> Oh, I can read.
[22:41]  * belkinsa facepalms!
[22:42] <belkinsa> I shouldn't be multitasking.
[22:42] <dsmythies> KI7MT, Yes many many things need adding or updating
[22:42] <belkinsa> ;)
[22:43] <KI7MT> dsmythies, Yes, fare enough, not beating on that, what Im after is, should help.ubuntu.com match up with the Server & Desktop guides? In other words, if we edit / update one, should all three not get the updates?
[22:43] <KI7MT> Or should thing like ...
[22:44] <KI7MT> sshd-server only be in the server guide and links form Desktop & help to the server pages
[22:44] <KI7MT> Reason I ask is, I found three different pages for OpenSSH Server Config ...
[22:45] <dsmythies> help.ubtuntu.com is not updated very often. I have been the one doing it os recent, and I only do it later in the cycle for a prepliminary version and then again on the release date for the final version.
[22:45] <KI7MT> In my mind, while one could have an an sshd on their desktop .. should the configuration of that server be in the server guides or help adn desktop too ?
[22:47] <dsmythies> Good question, I don't really know, but earlier others were mentioning "double-maintaining", and we should strive for no double-maintaining.
[22:47] <KI7MT> and what's drive that quesiton is, the untold numerb of folks that pop into #ubuntu wih questions. I really dont like to send someone asking about Ubuntu things, to a non-ubuntu site for info, but sometimes, allot of times, we have too.
[22:47] <dsmythies> Myself, I am only familiar with the serverguide version of openssh-server.
[22:48] <KI7MT> dsmythies, That's ok, fare enough, was jsut usign that as an example.
[22:50] <KI7MT> Wherein the Desktop has many itmes exclusive to the DE, the server has many items that can cross over, figuring out where the docs should be, well that's kinda what I was tryign to get my head around.
[22:54] <dsmythies> shaunm, are you still around?
[22:59] <dsmythies> KI7MT, is that an amateur radio call sign? If yes, mine is VE7NP
[22:59] <KI7MT> Yes, .. howdy neighbor :-)
[23:01] <KI7MT> think I finally have this Nick/Clak thing figured out.
[23:01] <KI7MT> Nick/Cloak


 Does for me almost every time
[12:13] <Riddell> apokryphos: that's plone that does that and it's a reported problem with kiohttp
[12:13] <Riddell> cmf: nope, that's the point of a wiki :)
[12:13] <apokryphos> Yup; that's what runs up.
[12:14] <cmf> Riddell: fair
[12:17] <Riddell> apokryphos: killall -9 kio_http  and reload the page seems to be the best you can do
[12:17] <apokryphos> Yup, that's what I end up doing generally.
[12:37] <uniq> who asked about rosegarden?
[12:38] <Riddell> uniq: cmf did
[12:38] <uniq> debian got 1.0-1 in sid.
[12:38] <uniq> we have 0.9.9-1 in universe..
[12:39] <Riddell> is that so...will have to see what can be done about that then :)
[12:39] <Riddell> but not tonight
[12:40] <uniq> :)
[12:41] <mdz> Riddell: what's pulling pccts into main, and has pitti reviewed it?
[12:42] <Riddell> mdz: never heard of it
[12:42] <elmo> it's a b-d of cdrdao
[12:42] <amu> mdz: cdrdao
[12:42] <mdz> oh, gah
[12:43] <mdz> I thought we had established that k3b did not depend on cdrdao anyway?
[12:43] <amu> https://bugzilla.ubuntu.com/show_bug.cgi?id=7877
[12:57] <AMIGrAve> is there a kubuntu-dev mailing list ?
[12:57] <Riddell> AMIGrAve: yep
[12:58] <AMIGrAve> Riddell: it is not mentionned on http://www.kubuntu.org.uk/faq.php
[12:58] <AMIGrAve> Riddell: made a patch for qtorrent wich won't run with the new pyqt, I send it on ubuntu dev or kubuntu dev ?
[12:59] <mdz> amu: new packages cannot enter main without review
[12:59] <mdz> amu: pitti reviewed cdrdao, but no one mentioned pccts
[12:59] <Riddell> AMIGrAve: groovy, kubuntu-devel please
[12:59] <Riddell> AMIGrAve: pyqt will probably be updated again soon
[12:59] <Riddell> AMIGrAve: or open a report on bugzilla
[01:00] <Riddell> AMIGrAve: actually you can't do bugzilla because it's universe, use the mailing list
[01:00] <AMIGrAve> Riddell: I'll send a mail so I can CC the author of qtorrent
[01:01] <mdz> Riddell: universe reports go to Malone now
[01:01] <mdz> there's a hyperlink from bugzilla
[01:01] <Riddell> ah cool
[01:09] <amu> mdz: haggai: arg, i will change it back, and add a suggest line. I suggest, let the waring exist, that there is no cdrao, user should install it himself for now.
[01:11] <Riddell> can we not get cdrdao in main if it gets changed to be not setuid?
[01:13] <motaboy> Night All!
[01:19] <amu> Riddell: it's already not suid, the problem are the depends of cdrdao, which are not checked by pitti, pitti checked only cdrdao
[01:20] <Riddell> right
[01:25] <Riddell> AMIGrAve: I've added a note about kubuntu-devel to https://www.ubuntulinux.org/wiki/HelpingKubuntu and added a link to that from the faq
[01:26] <AMIGrAve> Riddell: ok, i'm not sure the mail I sent to kubuntu-dev has acutally be sent (gmail trouble). If it's not, here are the patches : http://www.amigrave.com/upload/posts/qtorrent/
[01:27] <AMIGrAve> Riddell: do you get some sleep sometimes ? ;-)
[01:28] <Riddell> AMIGrAve: kubuntu-devel got an e-mail from<EMAIL_ADDRESS>[01:30] <AMIGrAve> Riddell: is there a WNPP for kubuntu ?
[01:30] <Riddell> AMIGrAve: what's one of those?
[01:31] <cartel_> riddell: debian use it as a list of orphaned/wishlist packages
[01:31] <AMIGrAve> Riddell: http://www.debian.org/devel/wnpp/
[01:31] <cartel_>  Work-Needing and Prospective Package
[01:31] <Riddell> oh right, no don't think so
[01:31] <Riddell> but there's wiki pages
[01:31] <Riddell> KubuntuSuggestedPackages is the one I pay attention to
[01:31] <cartel_> (k)ubuntu dont use itps either
[01:32] <cartel_> less beurocracy than debian
[01:32] <cartel_> but then kubuntu is much smaller
[01:32] <cartel_> in scope
[01:32] <AMIGrAve> Riddell: i'll study more the wiki instead of asking questions that are probably in it ;-) I was just asking because I would like to help
[01:32] <Riddell> AMIGrAve: asking is good
[01:32] <cartel_> amiga are you a debian developer?
[01:32] <cartel_> keysigned?
[01:33] <AMIGrAve> cartel_: no, I even don't know yet how to package deb's ;-)
[01:33] <cartel_> AMIGrAve: just read the debian new maintainers guide
[01:33] <cartel_> :)
[01:34] <AMIGrAve> cartel_: I wanted to learn that before but when I saw of difficult it was to help in debian I dropped
[01:34] <AMIGrAve> cartel_: yep I saw a link in the wiki, i'll learn that
[01:34] <Riddell> AMIGrAve: welcome to kubuntu :)
[01:34] <AMIGrAve> thanks ;-)
[01:35] <AMIGrAve> you all here have full time job outside of the pleasure of working on kubuntu ?
[01:35] <Riddell> why would we want one of those?
[01:36] <AMIGrAve> earn money to feed the pets, things like that ;-)
[01:37] <Riddell> the household cat is quite fat enough, I'm going to refuse to feed him soon
[01:37] <cartel_> i unfortunately have a full time job
[01:38] <uniq> I do to.
[01:38] <uniq> full time + some..
[01:39] <AMIGrAve> yeah me too
[01:40] <AMIGrAve> cartel_: how much time per week do you give to kubuntu ?
[01:40] <cartel_> none at the mo!
[01:41] <uniq> I'm thinking of getting a mac mini.. nice little box..
[01:42] <AMIGrAve> work in 6 hours going to bed, see you soon
[01:49] <Riddell> cartel_: what's that?
[01:51] <apokryphos> Riddell: is knemo in properly? It's installed, but doesn't seem to be addable when trying to add applet
[01:52] <uniq> apokryphos: it's not applets.. it docks a icon into the systemtray for each device you add.
[01:53] <apokryphos> uniq: I know :). But to add it, do you not Configure Panel > Add to Panel > Applet
[01:53] <uniq> no.
[01:53] <Riddell> never used knemo
[01:53] <uniq> you configure it in control center.
[01:53] <cartel_> Riddell: triplea.sourceforge.net :)
[01:53] <cartel_> its not in debian
[01:54] <apokryphos> I'm almost 90% sure that you should be able to add it that way. Quite sure I did it like that in the past
[01:54] <uniq> control center - internet & network - network monitor
[01:55] <apokryphos> Ah, control centre part is new in 0.3.1
[01:58] <dato> I believe it's in kalyxo, though
[01:58] <cartel_> dato: what is?
[01:59] <dato> knemo
[02:02] <uniq> it's in universe too.
[02:09] <uniq> systray full of crap.. even when most of the icons are hidden.
[02:56] <uniq> gnite guys.
[10:29] <haggai> amu: I already spoke to pitti about cdrdao on #ubuntu-devel, and I agreed with him to use the internal pccts.  I didn't say to you I was ready with cdrdao...
[02:43] <uniq> riddell: http://frode.kde.no/ubuntu - rosegarden4 packages for review. basically sid packages recompiled.
[04:37] <ttf> Kamion: some time back I've reported that even if you say "No" to download the language pack during install it will download it - has this been fixed?
[04:38] <Kamion> ttf: yeah
[04:38] <Kamion> should've been anyway. try a current daily
[04:39] <ttf> k - thanks
[06:32] <mdz> morning
[06:34] <mdz> I'd like to catch up with you guys about kubuntu release status and any outstanding issues
[06:34] <mdz> when would be a good time?
[06:35] <Riddell> mdz: I'm here, any time is good for me I think
[06:35] <mdz> ok
[06:35] <mdz> amu,haggai?
[06:36] <haggai> mdz: yup
[06:37] <haggai> mdz: I'm available all this evening
[06:39] <Riddell> libtunepimp is still brining libmad onto the CD, do we need to recompile that?
[06:40] <haggai> Riddell: what needs that?  Can the depends be overriden?
[06:40] <Riddell> haggai: juk, amarok
[06:42] <haggai> hmm it links directly to libmad :(
[06:42] <mdz> I can catch up with amu another time, let's talk now since you're both here
[06:43] <mdz> we'd like to start a test cycle today or tomorrow
[06:43] <Riddell> mdz: testing CDs?
[06:44] <mdz> yes
[06:45] <mdz> preparing for the final release on Friday
[06:46] <Riddell> ok, what do we need to do?
[06:48] <haggai> libtunepimp looks bad, it links directly to libmad, and is directly linked to by the juk and amarok binaries
[06:48] <Riddell> haggai: it can be compiled to not use libmad easily enough, but presumably you then loose MP3 tagging ability
[06:49] <haggai> Riddell: yes :(
[06:49] <Riddell> but I'm not sure why juk uses libtunepimp when it has taglib
[06:53] <haggai> mdz: so, outstanding issues I have are cdrdao and the mp3 issues.  I'm trying to get xine tp use the external libmad atm
[06:54] <mdz> haggai: I thought cdrdao was a non-issue, or that we only needed to disable the complaint
[06:55] <Riddell> I'm looking at a couple of changes to the menus.  also I'm trying and failing to make sense of python-kde3 which just doesn't want to work, but that's in universe.  also akregator konq plugin has disappeared
[06:55] <mdz> Riddell: I didn't think libmad had tagging functionality at all
[06:55] <Riddell> mdz: no, libtunepimp does and it depends on libmad
[06:56] <mdz> Riddell: but libtunepimp should be able to tag mp3s without libmad
[06:56] <haggai> mdz: cdrdao does a better job of cd writing in dao mode than cdrecord
[06:56] <haggai> mdz: k3b chooses it when available for certain tasks
[06:56] <haggai> mdz: so I wanted to get it into main
[06:56] <mdz> it's quite late to add new packages to the desktop
[06:57] <mdz> adding it to supported should be achievable
[06:58] <haggai> what are you thinking of re adding to desktop?  It does not install anything other than binaries that are used by k3b, so I don't see a big danger here
[07:00] <Riddell> haggai: I suspect libtunepimp is only used by musicbrains and not as the main tagger for both juk and amarok
[07:04] <apokryphos> (amaroK uses solely TagLib)
[07:04] <Riddell> apokryphos: but it also depends on libtunepimp
[07:05] <apokryphos> yah, for MusicBrainz
[07:07] <Riddell> I don't get why musicbrains doesn't depend on libtunepimp then instead of juk and amarok having to do it
[07:08] <apokryphos> MusicBrainz is optional... amaroK doesn't depend on it; only amaroK with Musicbrainz support
[07:13] <haggai> apokryphos: the problem is, amarok links directly to the libs so we can't make it optional at runtime
[07:13] <Riddell> I think that removing libmad from tunepimp is the best way, you loose musicbrains support but not general tagging
[07:14] <apokryphos> ah; quite a pickle.
[07:14] <haggai> Riddell: right, sounds like it then
[07:14] <haggai> python-tunepimp also uses libtunepimp but there are no packages that use it
[07:16] <haggai> in libtunepimp configure.in:
[07:16] <haggai>              echo "*  The MAD mp3 decoder is not installed. Please download "
[07:16] <haggai>              echo "*  the decoder from http://www.mars.org/home/rob/proj/mpeg"
[07:16] <haggai>              echo "*  to include MP3 TRM generation capabilities."
[07:17] <haggai> TRM creates a unique signature by analyzing thirty-seconds of an audio file for data values relating to a number of acoustic features
[07:17] <Riddell> haggai: doesn't sound like too great a loss then
[07:18] <Riddell> I'll upload a new tunepimp
[07:18] <dato> er
[07:19] <dato> nah, nvm. you loose the posibility of asking musicbrainz about mp3 files, but guess it's ok
[07:21] <Riddell> better than removing musicbrainz from juk and amarok which is the other alternative
[07:25] <Riddell> haggai: any opinion on having the kmenu use 32x32 icons?
[07:27] <haggai> Riddell: looking at libtunepimp it seems the API/ABI does not change when you have libmad support, so people will be able to install a libmad-enabled package without needing to recompile juk/amarok
[07:28] <haggai> Riddell: (icons) just the top level, or all levels?
[07:42] <mdz> haggai: re: adding to desktop, I was thinking about cdrdao
[07:42] <mdz> but if you only want it in supported, I think that's fine (given that the build-dependency is sorted out)
[07:43] <mdz> do you guys have a preference between a separate Kubuntu announcement, and a joint announcement with Ubuntu?
[07:46] <haggai> I think we should do 2 announcements.  The kubuntu announce went a bit unnoticed tucked away below the ubuntu rc
[07:47] <haggai> so I think 2 seperate mails to -announce would be better
[08:47] <motaboy> allee: hi!
[09:08] <allee> motaboy: hi!
[09:08] <allee> motaboy: any news from the kbt front?
[09:55] <motaboy> allee: none that I know. I'm trying to implement a debian alternatives for kbluepin
[09:55] <motaboy> allee: BTW are you the digikam mantainer?
[09:56] <allee> motaboy: yes. (we are three but the other two are quite busy for work/family)
[09:56] <motaboy> allee: Is there an updated version for ubuntu?
[09:57] <allee> motaboy: yes wait ...
[09:57] <allee> http://www.mpe.mpg.de/~ach/kubuntu/hoary/Pkgs.php
[09:58] <allee> debian sid only is some minor cosmetics ahead
[10:00] <allee> motaboy: alternatives, like /etc/alternatives or a wrapper script that calls kbluepin, bluepin-* depending on enviroment?
[10:00] <allee> bb in some minute
[10:00] <allee> s
[10:00] <motaboy> allee: I was thinking about /etc/alternatives like suggested by haggai
[10:02] <allee> motaboy: I'm not fan of such a solution because life is sometimes more complicated that 'everyone' uses KDE on this host ...
[10:02] <allee> motaboy: but admitted it's better than the current 'edit the config file'
[10:15] <mdz> haggai: ok, that can be arranged.  would one of you like to do the kubuntu announcement?
[10:17] <motaboy> allee: The wrapper can be a good idea, but I don't know how to get which de is running and how a users can override this choose with a preferred one.
[10:29] <allee> motaboy: hmm, right it's still tricky.  maybe having kbluetooth register with dbus like the python-dbus script would be much simpler
[10:32] <allee> motaboy: sorry, bluez-pin isn't (was it ever?) a python script :(
[11:04] <Kamion> there are new Kubuntu daily install/live CDs up with most of today's installer changes (mostly just translations, but some a bit more intrusive), if folks want to test
[11:07] <elmo> Riddell: ?
[11:07] <elmo> Riddell: your clock is broken and it's causing your gwenview upload to FTBFS
[11:11] <haggai> mdz: ok, when do you need it?
[11:11] <mdz> haggai: thursday evening UTC
[11:11] <mdz> also, as Kamion mentioned, there's a new set of CDs up, and they need to be tested
[11:12] <haggai> great thanks we'll get going on them
[11:15] <mdz> for the next few days, it would be a good idea to regularly sync up so that you're never far away from the latest ISO via rsync
[11:23] <haggai> yes I had been until the daylies stoped
[11:27] <cmf> uniq: hi, rosegarden pkg seems good, but as i requested in my comment, could you rename the executable to rosegarden rather than rosegarden4? also there doesn't seem to be an icon installed
[11:27] <cmf> uniq: also the kmenu entry is rosegarden 4? should it not just be rosegarden?
[11:27] <mdz> haggai: they only stopped for a short time around RC
[11:28] <haggai> mdz: ah ok
[11:28] <cmf> uniq: and no icon in titlebar ot taskbar, just teh blank document one when no icon is present, aside from that all good, thanks
[11:28] <mdz> haggai: see #ubuntu-devel scrollback for the past 10 minutes or so, if you're seeing old ISOs
[11:29] <uniq> cmf: I'll look into those glitches.
[11:29] <cmf> uniq: thanks :)
[11:29] <uniq> now it's basically a copy of the package from debian sid..
[11:30] <haggai> mdz: thanks, looks like my first connection is ok
[11:34] <uniq> cmf: you have /usr/share/applnk/Multimedia/rosegarden.desktop don't you?
[11:36] <uniq> there are icons too.. dpkg -L rosegarden4|grep rosegarden.png
[11:36] <uniq> and two rosegarden.xpm's.
[11:37] <cmf> yeah, there are icons, but when ypu type "rosegarden4" into run, it's just the cog, no rosegarden icon, and title bar and taskbar are the blank icon (blank page thing)
[11:37] <uniq> ah..
[11:38] <uniq> input into run is easy to fix.. either rename the binary to rosegarden.. or rename the icons to rosegarden4.png
[11:39] <uniq> I'll fix it in the package.
[11:39] <cmf> okies
[11:39] <cmf> you renaming th ebin?
[11:40] <uniq> I'll look into coexsisting with rosegarden2..
[11:41] <cmf> okies
[11:41] <cmf> but isn't rosegarden2 depreciated?
[11:41] <cmf> and unmaintained?
[11:41] <haggai> and not in ubuntu
[11:41] <uniq> dunno. it's in universe.
[11:41] <haggai> oh :)
[11:41] <uniq> .. or not?
[11:41] <uniq> Filename: pool/universe/r/rosegarden2/rosegarden2_2.1pl4-2_amd64.deb
[11:42] <uniq> if we could remove that.. it wouldn't be a problem at all.
[11:42] <haggai> rosegarden - An integrated MIDI sequencer and musical notation editor
[11:42] <haggai> rosegarden2 - An integrated MIDI sequencer and musical notation editor
[11:42] <haggai> rosegarden4 - Music Editor and MIDI/Audio Sequencer
[11:42] <haggai> hmm
[11:42] <uniq> rosegarden is rosegarden2.
[11:42] <uniq> rosegarden4 is the only useable.
[11:43] <haggai> I think I'd just conflict with the others, and start procedures to get rosegarden removed
[11:43] <haggai> well, rosegarden2 removed :)
[11:43] <uniq> sure.
[11:44] <uniq> /usr/bin/rosegarden2
[11:44] <uniq> i think we safely can use /usr/bin/rosegarden
[11:44] <haggai> yup, and conflict with rosegarden2, rosegarden
[11:44] <uniq> and maybe change the rosegarden package.. to be a meta-package for rosegarden4 instead.
[11:45] <uniq> wouldn't need to conflict..
[11:45] <uniq> rosegarden2 uses /usr/bin/rosegarden2..
[11:45] <haggai> or.. just rename the whole thing to rosegarden
[11:45] <haggai> (package)
[11:45] <uniq> even better.
[11:46] <uniq> that's probably the best solution.
[11:46] <uniq> haha..
[11:46] <uniq> rosegarden2 is -OLD-
[11:47] <uniq> "One of the Rosegarden programs has just died, horribly."
[11:47] <uniq> heh.. nice.
[11:48] <haggai>   * The package for rosegarden 2.1 has been renamed to "rosegarden2"
[11:48] <haggai>      "rosegarden" is now a dummy package depending on "rosegarden2". In
[11:48] <haggai>      future Debian releases "rosegarden" will be the Debian package
[11:48] <haggai>      holding Rosegarden version 4, now in package "rosegarden4".
[11:48] <uniq> in future versions :)
[11:48] <haggai> last upload was 2004-08-14 :)
[11:49] <haggai> so that doesn't reflect the 1.0 upload yet
[11:50] <haggai> I'd say 1.0 is a pretty good future version to do the rename
[11:55] <uniq> the ap is actually reffered to as rosegarden 4 on the project homepage..
[11:55] <uniq> http://www.rosegardenmusic.com/
[11:55] <uniq> ap/app
[11:56] <uniq> maybe it's better to make a replacement rosegarden package.. that depends on rosegarden4.. instead of renaming the package.. what do you think?
[11:57] <uniq> the rpms are named rosegarden4
[11:59] <cmf> i think just naming rosegarden, but that's just me...
[11:59] <uniq> it's probably easier.


[03:04] <Sarvatt> tormod: yeah its just because you were building all those drivers in drivers-only without macros 1.3 that they all require now
[03:05] <Sarvatt> oh darn he isnt here
[08:39] <tjaalton> whoa, wacom 0.10.1 doesn't rely on hal nor libudev, but queries the kernel directly for the capabilities
[08:40] <tjaalton> is tormod a DD now?
[08:41] <hyperair> is that a good thing or a bad thing?
[08:41] <tjaalton> both are good, if true :)
[08:41] <hyperair> hmm that's cool =p
[08:41] <hyperair> but wouldn't that require a bit of reimplementation of things?
[08:42] <tjaalton> it's done in the driver
[08:42] <tjaalton> hmm, 98 packages to update in debian
[08:42] <hyperair> by driver you mean kernel module or what?
[08:43] <tjaalton> no, the X driver
[08:43] <hyperair> ah
[08:43] <tjaalton> I've only read the announce, nothing more :)
[08:43] <tjaalton> +ment
[08:43] <hyperair> i see
[08:45] <tjaalton> tseliot: hey, check the wacom 0.10.1 announcement ;)
[08:46] <tseliot> tjaalton: let me check xorg-announce
[08:47] <tseliot> tjaalton: now *that* is what I call a cool release. Do we need a new kernel?
[08:47] <tjaalton> tseliot: no idea, I think not
[08:48] <tseliot> it's definitely something that I have to try
[16:16] <Sarvatt> nice, building that new wacom on edgers to try it out
[17:27] <tjaalton> bryce: there's a fresh wacom that queries the kernel for the device properties, so no hal or udev is needed :)
[17:27] <Sarvatt> there we go, took a ton of rule changes since the 0.8.4 versions but wacom 0.10.1 is working now in edgers lucid repo under xorg 7.5/xserver 1.8 if anyone wanted to try it
[17:28] <tjaalton> I don't think there's sense in using the old wacom-tools as a base
[17:28] <tjaalton> bah, gotta go ->


[08:25] <JamesTait> Good morning all; happy Monday and happy Fresh Veggies Day! :-D
[13:23] <dobey> JamesTait: fresh veggies day was last tuesday