[00:00] <thumper> jason955: you sould be able to configure each mysql deploy to use a different port
[00:00] <thumper> jason955: and use the placement directive --to in order to put them on the same machine
[00:00] <jason955> I understand the placement directive.  So you are able to configure the port then.... Is this true for most charms?
[00:05] <thumper> jason955: I expect so, I think it is something the charm reviewers look for
[00:05] <thumper> minimal hard coding
[00:05] <thumper> sensible defaults but configurable
[00:07] <jason955> awesome, Juju is pretty exciting stuff!
[00:07] <jason955> also, currently I have a web server that that serves some static HTML for some pages and forwards to a WSGI service with an http proxy.  Is it possible to do this with Juju?  I see that I can make web servers but can you perform path-based routing?
[00:11] <jason955> or is there a way to just do domain based routing? to multiple proxy servers behind a main apache instance?
[00:17] <jason955> perhaps an example would be helpful: apache or nginx as the front web server.  A couple of different gunicorn instances behind the web server.  Can I configure the webserver to route to the different gunicorn relationships based on the top level domain being requested?
[00:18] <marcoceppi> jason955: the apache 2 charm allows for this
[00:19] <jason955> Thanks.  I assume I just have to ssh into the charm and configure the apache files?
[00:20] <sarnold> jason955: some details can be found here: http://manage.jujucharms.com/charms/precise/apache2
[00:20] <marcoceppi> jason955: note you can do it via charm configuration
[00:20] <sarnold> looks very nice :)
[00:21] <jason955> awesome.  Exactly what I was looking for!
[00:21] <jason955> nice video BTW marco
[00:21]  * thumper goes to do some work
[00:21] <marcoceppi> jason955: thanks! which one are you watching?
[00:22] <jason955> How to use the Local/LXC Provider (August 2013)
[00:22] <jason955> watched it last night
[00:24] <marcoceppi> awesome
[00:38] <freeflying> any doc for juju use tag to specify maas machine when deploy
[01:37] <marcoceppi> freeflying: https://juju.ubuntu.com/docs/charms-constraints.html#constraints-maas
[01:39] <freeflying> marcoceppi, figured out, thanks
[08:04] <nesusvet> hello everyone. I can't destroy machine which status is pending
[09:16] <davecheney> nesusvet: not at the moment i am afraid
[09:17] <nesusvet> Hmm, so what should I do? )
[09:18] <davecheney> nesusvet: can you paste the status of the machine
[09:18] <davecheney> ?
[09:18] <davecheney> ie, why isn't it going to come up
[09:18] <nesusvet> I tried to reboot it, and after this it's disappeared, but when I add it again, it has the pending status again
[09:19] <nesusvet> davecheney,   http://pastebin.com/E1pbwBdb
[09:19] <davecheney> nesusvet: are you canonical ?
[09:20] <nesusvet> nope
[09:20] <davecheney> ok, jus tchecking
[09:20] <davecheney> short answer is
[09:20] <davecheney> once you giv ethat machine to juju
[09:20] <davecheney> you can't touch it
[09:20] <davecheney> i'm afraid there is currently no provision for removing that machine from status
[09:20] <davecheney> and as a pending machine with no units assigned to it
[09:20] <davecheney> it iwll attract a unit and fail to deploy it
[09:21] <davecheney> the solution at the moment is to destory your environment and start again
[09:21] <davecheney> i am sorry
[09:21] <nesusvet> ohh
[09:21] <nesusvet> sound bad )
[09:21] <nesusvet> sounds*
[09:21] <nesusvet> well I will do
[09:21] <davecheney> you mustn't use the maas console once themachine has been assigned to juju
[09:21] <davecheney> otherwise it'll all go wrong
[09:23] <nesusvet> I did't use maas at all (
[09:24] <nesusvet> all that I did, just sshed on it and reboot
[09:24] <davecheney> yeah, you can't do that either
[09:24] <davecheney> once juju is reponsible for the machine you must not touch it
[09:24] <nesusvet> I see
[09:24] <davecheney> otherwise juju will get out of sync
[09:24] <nesusvet> thanks )
[09:25] <nesusvet> but if I deploy thousand of server, so it might be dangerous. it's not flexible way (
[09:25] <nesusvet> Well, I have another question.
[09:25] <davecheney> nesusvet: we're working on fixing it
[09:25] <davecheney> i'm sorry the fix isn't available yet
[09:26] <nesusvet> Can I deploy the juju agent on the node where maas is located?
[09:26] <davecheney> the solution is to use maas tags
[09:27] <davecheney> you can use juju deploy --constraint="maas-name=XXXX"
[09:27] <davecheney> i am not sure if it is available yet
[09:27] <davecheney> it may be in version 1.16
[09:28] <nesusvet> interesting. But juju does't see this machine.
[09:29] <nesusvet> I tryed to do juju add-machine ssh:ubuntu@ip-address
[09:29] <davecheney> nesusvet: ok, that is different
[09:29] <davecheney> are you using the maas provider
[09:29] <nesusvet> yes
[09:29] <davecheney> or the ssh/manual/null provider ?
[09:29] <davecheney> ok, the maas provider cannot provision ssh: machines
[09:29] <davecheney> that is the ssh provider
[09:30] <nesusvet> It's not clear part for me.
[09:30] <davecheney> i'm sorry, you cannot mix and match providers in a single environment
[09:30] <nesusvet> But after this action juju started seeing my maas machine.
[09:30] <davecheney> i cannot explain that
[09:31] <nesusvet> Do you mean, I can install juju agents's on the target machines even in case if I don't have maas?
[09:32] <davecheney> you can do this
[09:32] <davecheney> it's called the manual provider
[09:32] <davecheney> each environment can be managed by a single provider
[09:32] <davecheney> if you want to use the manual provider
[09:33] <davecheney> those machines will be provisioned in a different environment
[09:33] <davecheney> and will be unable to form relations to the machines in your maas environment
[09:33] <davecheney> (even though you may have asked maas for machines and provisioned them manually)
[09:54] <nesusvet> Thank you very much, davecheney
[09:54] <nesusvet> Now it's clear
[09:54] <davecheney> nesusvet: happy to help
[14:40] <Tribaal> Hi all, I need some help debugging some juju/maas interaction. Is this the correct channel or should I jump to #juju-dev ?
[14:44] <dpb1`> Tribaal: what do you need?
[14:45] <marcoceppi> Tribaal: we shoud be able to help here. Those in #juju-dev are also here
[14:47] <Tribaal> I setup a local KVM MaaS server that spins up other KVM nodes via PXE - that seems to work fine. I pointed juju at it, and a "juju bootstrap" spun up a node ("juju status" reports). Spinning up charms however does not work - the nodes are started and provisionned (ubuntu installed), but they are stuck in a pending state forever
[14:47] <Tribaal> let me paste the juju logs
[14:47] <Tribaal> http://pastebin.ubuntu.com/6370847/
[14:48] <Tribaal> that's the only file in /var/log/juju
[14:49] <Tribaal> "juju ssh" to the machine works
[14:49] <Tribaal> the nodes can see the internet and talk to each other just fine
[14:49] <dpb1`> weird: 2013-11-06 13:40:26 ERROR juju runner.go:211 worker: exited "deployer": exec ["start" "--system" "jujud-unit-mysql-0"]: exit status 1 (start: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory)
[14:49] <Tribaal> right
[14:49] <Tribaal> so I ran this by hand
[14:49] <Tribaal> it succeeds without the "--system"
[14:49] <Tribaal> but then another log shows up in /var/log/juju
[14:50] <Tribaal> repeating "/bin/sh: 1: exec: /var/lib/juju/tools/unit-mysql-0/jujud: not found"
[14:50] <Tribaal> the tools directory has a machine-1 symlink, but no unit-* symlink
[15:10] <dpb1`> Tribaal: is this from trunk or from the ppa?
[15:13] <Tribaal> dpb1`: whatever comes from saucy - from teh node: http://pastebin.ubuntu.com/6370948/
[15:13] <Tribaal> dpb1`: is that what you meant?
[15:13] <dpb1`> Tribaal: also, it seems weird that it's passing --system ??
[15:13] <Tribaal> indeed
[15:14] <dpb1`> Tribaal: what version of juju do you have on your system where you are initating commands?
[15:16] <Tribaal> dpb1`: from the initiator: http://pastebin.ubuntu.com/6370959/
[15:16] <dpb1`> OK good
[15:16] <dpb1`> stable ppa
[15:22] <dpb1`> Tribaal: these are precise boxes?
[15:22] <Tribaal> saucy
[15:22] <oatman> hi all, where would I look for advice on using the gunicorn charm (http://manage.jujucharms.com/charms/precise/gunicorn) ?
[15:23] <oatman> ie, I am writing a WSGI process, I guess I want to charm up my app and link it to the gunicorn charm some how, is it a subordinate?
[15:28] <marcoceppi> oatman: yeah, the gunicorn charm is an interesting on
[15:28] <marcoceppi> one
[15:29] <oatman> describing the charm as "interesting" is in itself interesting. Why so?
[15:29] <marcoceppi> oatman: I've not used it and it's usecase alwasy seemed very narrow to me
[15:30] <marcoceppi> oatman: I'd look in to how python-moinmoin charm works with this as it's what the author developed the charm to work with originally
[15:30] <oatman> ah, good plan
[15:30] <oatman> I had noticed the reference in the readme
[15:30] <oatman> thanks marcoceppi
[15:55] <jcastro> marcoceppi, after I bzr pull in your charm tools dir I need to do X to install it?
[15:55] <jcastro> solve for X please
[15:55] <marcoceppi> jcastro: use the PPA
[15:55] <marcoceppi> 1.1.2 and trunk are the same at this time
[15:55] <jcastro> which ppa?
[15:55] <marcoceppi> ppa:juju/stable
[15:57] <marcoceppi> jcastro: wait, you've manually installed
[15:57] <marcoceppi> you're going to have to clean a few things up
[15:58] <marcoceppi> manual install and ppa will just stomp all over eachother
[16:06] <jcastro> marcoceppi, ack, how do I blow away the manual install?
[16:07] <jcastro> arosales, when you get a chance today can you look at the sessions in the sidebar
[16:07] <jcastro> we are out of slots and we're going to have to cut some sessions
[16:07] <jcastro> so we need to prioritize
[16:10] <arosales> jcastro, will do
[16:10] <jcastro> arosales, we only need to cut like 3 sessions or so
[16:11] <arosales> jcastro, thats not bad
[16:11] <jcastro> I asked for more room in an empty track but that's not happening, so we need  to cut the fat
[16:12] <jcastro> other than that, our schedule for UDS is basically done, I'll post to the list
[16:36] <marcoceppi> jcastro: rm -rf /usr/bin/juju-charm /usr/bin/charm-* /usr/bin/juju-bundle /usr/local/lib/python2.7/dist-packages/charmtools
[16:36] <jcastro> ta
[16:36] <marcoceppi> jcastro: then re-install the package
[16:38] <jcastro> got it, thanks!
[16:54] <rick_h_> hazmat: ping, jujuclient review if you get a few min we need to release bundles. https://code.launchpad.net/~rharding/python-jujuclient/adjust_constraint_handling/+merge/194176
[16:54] <rick_h_> hazmat: we'll have more coming, but after the release I think.
[16:58] <marcoceppi> hey party people: https://plus.google.com/hangouts/_/76cpj8gt7n29nu6ni5gl7sq9j0?authuser=0&hl=en
[16:59] <marcoceppi> Charm status in a few mins
[16:59] <marcoceppi> evilnickveitch:
[17:00] <marcoceppi> http://youtu.be/CNb3J92TU94
[17:22] <mind_> mims is gone!! no wonder no one has reviewed my charm modifications.
[17:27] <mind_> jcastro: who should I request to review my node-app modifications. Did a bunch of things Mims asked for before he wanted to approve changes to it(hash check, default app, and source code install with option for repository install).
[17:27] <jcastro> hi mind_!
[17:27] <jcastro> let me check it out
[17:27] <jcastro> do you have a bug # handy by any chance?
[17:28] <mind_> https://code.launchpad.net/~web-brandon/charms/precise/node-app/install-fix
[17:28] <mind_> not a bug was just making it better
[17:28] <scuttlemonkey> so is it possible to use juju on a set of established servers yet?
[17:29] <scuttlemonkey> I know there was a request for that a while back
[17:29] <jcastro> scuttlemonkey, pretty close
[17:29] <scuttlemonkey> ahh neat
[17:29] <jcastro> next stable release probably
[17:29] <scuttlemonkey> unfortunately that doesn't help me w/ the demo I'm building now on a rack for SC13 :)
[17:29] <scuttlemonkey> alas
[17:29] <jcastro> https://juju.ubuntu.com/docs/config-manual.html
[17:29] <jcastro> hmm, how is this MP not in the queue
[17:30] <mind_> is there a preffered repo for charmtools still or is the best version part of the main branch now
[17:30] <jcastro> the stable PPA is what you want
[17:30] <jcastro> mind_, ok I've subscribed it to the ~charmers team
[17:30] <jcastro> should be reviewable next in the queue
[17:30] <jcastro> marcoceppi, ^^^
[17:30] <mind_> thank you
[17:31] <jcastro> jcsackett, any idea why that branch wouldn't show up in the queue?
[17:32] <marcoceppi> webbrandon: jcastro: I'll have eyes on later today
[17:36] <webbrandon> thank you as always marco
[17:41] <webbrandon> thank you for adding mongodump suport to mongodb juan
[18:06] <jcsackett> jcastro: it doesn't have charmers as a requested reviewer; looks like you and Mims were requested directly.
[18:06] <jcastro> oh weird, I thought all MPs to anything in the charms namespace was autoqueued
[18:07] <jcsackett> jcastro: no, it's any MP with charmers as the requested reviewer (which is the default for charms owned by ~charmers).
[18:08] <jcastro> huh, I wonder how this happened
[18:08] <jcastro> oh well, it's in the queue now
[18:08] <jcastro> webbrandon, have we sent you a juju shirt for your contribution?
[18:19] <scuttlemonkey> jcastro: can juju add-machine ssh: use .ssh/config to resolve somehow?
[18:19] <scuttlemonkey> I see ip, hostname, and full user@ip
[18:20] <jcastro> scuttlemonkey, so there were a bunch of issues that prevented manual from working
[18:20] <jcastro> I don't know if we've fixed those yet in the dev releases
[18:23] <jcastro> I can give it a shot after lunch
[18:23] <scuttlemonkey> ahh
[18:24] <scuttlemonkey> ok, so I'd have to pull from the dev ppa
[18:24] <jcastro> yeah
[18:24] <scuttlemonkey> may just use ceph-deploy and see if I can get there from here
[18:24] <jcastro> sinzui, do you know the status of manual provisioning in the dev releases offhand?
[18:24] <sinzui> No I don't
[18:25] <jcastro> scuttlemonkey, once it lands though it'll be so nice to deploy to like digital ocean, etc.
[18:26] <sinzui> jcastro, there is certainly one more bug that the devs want to include in a 1.17 release
[18:26] <sinzui> https://bugs.launchpad.net/juju-core/+bugs?field.tag=ssh-provider
[18:26] <scuttlemonkey> jcastro: yah, definitely
[18:37] <marcoceppi> jcastro: jcsackett it probably was originally assigned to charmers, when you claim review it's no longer assigned to charmers, so you need to make sure to say "When ready for another review, please "Requestion another review" from charmers"
[18:37] <webbrandon> I thought I remember someone saying a while back that juju-local bootstrap will no longer need to be done as a root, still coming or pipe dream?
[18:38] <jcastro> webbrandon, that's coming
[18:38] <webbrandon> :)
[18:44] <jcsackett> marcoceppi: that makes sense. jcastro ^
[18:44] <jcsackett> oh, nm, you were highlighted in that too.
[18:52] <webbrandon> jcastro no i havent gotten a shirt
[18:53] <webbrandon> would love one though
[18:53] <jcastro> webbrandon, pm or mail me your address and I can send you one<EMAIL_ADDRESS>[18:59] <arosales> sinzui, natefinch-afk: can you guys confirm the widows client got updated to 1.16.2 so it also receives the fix for https://bugs.launchpad.net/juju-core/+bug/1246320
[18:59] <_mup_> Bug #1246320: Azure bootstrap fails: versioning header is not specified <azure> <bootstrap> <Go Windows Azure Client Library:Fix Committed by wallyworld> <juju-core:Fix Committed by wallyworld> <juju-core 1.16:Fix Released by wallyworld> <juju-core trunk:Fix Committed by wallyworld> <juju-core (Ubuntu):Fix Released> <juju-core (Ubuntu Saucy):New> <juju-core (Ubuntu Trusty):Fix Released> <https://launchpad.net/bugs/1246320>
[19:00] <sinzui> arosales, yes, that is what we updated every link to https://juju.ubuntu.com/install/
[19:00] <arosales> sinzui, thanks for confirming.
[19:02] <webbrandon> jcastro I just emailed you (from brandon clark)
[19:02] <jcastro> cheers!
[19:18] <hazmat> rick_h_, why do you want that behavior?
[19:19] <hazmat> rick_h_, the client lib explictly avoids trying to do policy things.. ie. that whitelist already misses lots of constraints
[19:20] <rick_h_> hazmat: because bundles were failing to deploy from the gui silently because they had pyjuju style constraints. We spent a lot of time debugging it yesterday. Noted in there we want to try to work on getting messages/errors out of the client up to the deployer and back into the gui, but that's going to take some more work
[19:20] <rick_h_> hazmat: yea, it's a hacky temp fix. I pulled the list of suported gui juju-core constraints to check against
[19:21] <hazmat> rick_h_, sorry this is the right layer for a temp fix
[19:21] <hazmat> isn't
[19:21] <rick_h_> k
[19:21] <hazmat> rick_h_, deployer would be fine
[19:21] <rick_h_> k
[19:21] <hazmat> rick_h_, but its not really about white listing.. its about blacklisting
[19:22] <hazmat> rick_h_, there are new constraints all the time, and this white list already misses a few
[19:22] <rick_h_> hazmat: well we've talked about trying to be able to get a vocabulary from juju itself, but not available yet. Not sure how a blacklist would work best.
[19:22] <hazmat> rick_h_, you have a specific problem wrt to pyjuju compatiblity around constraint keys.
[19:23] <rick_h_> hazmat: well, around people manually creating deplyer files hand entering constraints, and those causing really impossible ot trace errors
[19:24] <hazmat> rick_h_, fair enough, but we don't really want to update a constraint list every time
[19:24] <rick_h_> hazmat: +1
[19:25] <hazmat> rick_h_, the real issue is the reporting. you have a specific case of pyjuju constraint keys that aren't valid against juju, you can play to that case in the app level (deployer or gui)
[19:25] <rick_h_> hazmat: ideally we'll get errors from the rpc call in the client, back to the deployer, to the guiserver, to the gui UX for users when it fails
[19:25] <hazmat> rick_h_, yeah, that error reporting would be ideal
[19:25] <rick_h_> I'm trying to unblock the bundles release asap with this fix. Understand if you'd prefer it happen elesewhere or differently.
[19:25] <hazmat> rick_h_, silently stripping the user input without feedback is likely to cause its own set of surprises.
[19:25] <rick_h_> the thought was that limiting the constraints of bundles while we get the reporting in place was a reasonable band-aid
[19:26] <rick_h_> hazmat: understood
[19:26] <hazmat> rick_h_, fair enough.. but the band aid should go as close to the app as possible, not prevent use in the client libs of valid constraints.
[19:33] <hazmat>  rick_h_ where does the reporting break errors back to the user breakdown?
[19:33] <hazmat> s/break/back
[19:34] <rick_h_> hazmat: so the client throws a EnvError that doesn't have the message from the rpc call
[19:34] <rick_h_> hazmat: so the deployer can check for EnvError, but the error isn't helpful
[19:35] <rick_h_> hazmat: and the deployer throws exceptions without any messages so it needs updating to get them back and the guiserver bits in there need to get it on the ws back to the gui charm
[19:35] <hazmat> rick_h_, so the client error message should have details
[19:36] <hazmat> rick_h_, if not thats a bug..
[19:36] <rick_h_> hazmat: yea, it'll be step 1
[19:36] <hazmat> rick_h_, the entire response is attached to the enverror so not clear how it goes missing
[19:38] <hazmat> rick_h_, step 1 afaics is really about fixing deployer err handling so that's its more suited for this as a  library usage instead of its current i'm a cli tool and i fail fast on error.
[19:39] <hazmat> rick_h_, what would the gui want  as a form of error?
[19:39] <rick_h_> hazmat: rgr, same type of stuff we're hitting with charmtools and proofing.
[19:39] <hazmat> rick_h_, yup
[19:39] <rick_h_> hazmat: not sure, atm debugging a charmworld release issue with webops so will have to get back with you
[19:39] <hazmat> rick_h_, is there any expectation or error handling for deploys in gui?
[19:39] <hazmat> k
[19:40] <rick_h_> hazmat: no, because it's async we fire the deploy request off and errors don't get back right now. At least in our debugging why come bundles were failing to work yesterday
[19:41] <hazmat> rick_h_, that sounds like a separate / additional issue with the guiserver deployer middleware.
[19:41] <rick_h_> hazmat: +1 the guiserver bit int he deployer needs to communicate errors back to the gui server in the charm
[19:42] <rick_h_> hazmat: right now, in env/gui.py it calls deploy and walks away
[19:43] <hazmat> rick_h_, and a common way to communicate errors is exceptions.. so three separate issues rich exception passthrough and handle exceptions at gui server, and ... implement error handling in the gui for bundles
[19:45] <rick_h_> hazmat: yes, that's the fix we want to do. To move forward today the band-aid fix came up. If it's not ok, then we'll do something else. However, trying to get to release today/tomorrow.
[19:46] <hazmat> rick_h_, the closest place to gui that's reasonable to do a hack is the guiserver deployer middleware
[19:46] <rick_h_> hazmat: rgr, will move the band-aid there for now then and we'll be fixing coms/deployer as a library as follow ups post-release
[19:49] <hazmat> rick_h_, sounds good
[20:44] <dpb1`> Hi all: how do I get something out of life: dying?  I want the service gone.
[20:52] <marcoceppi> dpb1`: are any of the units in a dying state?
[21:02] <dpb1`> marcoceppi: actually the units removed just fine
[21:02] <dpb1`> marcoceppi: but the service is still there.  dying. :)
[21:02] <marcoceppi> dpb1`: status output?
[21:03] <dpb1`> ya, sec
[21:03] <dpb1`> marcoceppi: pft, it's gone
[21:03] <dpb1`> marcoceppi: wdyd
[21:04] <marcoceppi> dpb1`: magic ;)
[21:04] <dpb1`> lol
[21:04] <dpb1`> well, that is fine with me.  I was too quick I think
[21:30] <webbrandon> hmmm nothing will install from apt-get if I use -y -qq options.  Getting a cgroup-lite error.  Haven't seen this before and this charm used to work.  On juju-local, anyone seen this?
[21:32] <marcoceppi> webbrandon: this is a known issue, being patched atm
[21:33] <webbrandon> GTK
[21:33] <marcoceppi> webbrandon: https://bugs.launchpad.net/ubuntu/+source/cgroup-lite/+bug/1247299
[21:33] <_mup_> Bug #1247299: local provider deploys fail with 'install hook failed' <local-provider> <juju-core:Fix Committed by thumper> <juju-core 1.16:Fix Released by thumper> <cgroup-lite (Ubuntu):Invalid> <https://launchpad.net/bugs/1247299>
[21:35]  * thumper sighs some more
[21:35]  * marcoceppi giggles
[21:35] <rick_h_> thumper: we <3 you for fixing it
[21:36] <thumper> if only everyone used juju from trunk
[21:36] <rick_h_> :)
[21:36] <thumper> there would be chaos everywhere
[21:36] <marcoceppi> mwhaha
[21:47] <webbrandon> Can't wait to see your fix in play thumper. Thank you
[21:47] <thumper> np
[21:51] <aaronfc> Hi
[21:52] <marcoceppi> hello aaronfc o/
[21:52] <aaronfc> I just bought a VPS (under OpenVz) with Ubuntu Server 13.04, and I want to use Juju.
[21:52] <aaronfc> I tried installing juju-local, but I get an error about "lxc"
[21:52] <marcoceppi> aaronfc: can you put your error on paste.ubuntu.com ?
[21:53] <aaronfc> sure! http://paste.ubuntu.com/6372971/
[21:54] <aaronfc> do you need full error ?
[21:55] <aaronfc> full error: http://paste.ubuntu.com/6372981/
[21:56] <thumper> aaronfc: I'd highly suggest not using juju-local on a VPS
[21:57] <thumper> aaronfc: the local provider is targetted for development purposes
[21:57] <thumper> and unless this is what you are wanting to use it for
[21:57] <thumper> it may be better to try the manual bootstrapping
[21:58] <thumper> aaronfc: the lxc service failed to start, logs probably in /var/log/upstart/lxc.log
[21:58] <aaronfc> I'm trying the juju-local because I thought it was the only option without using a cloud service provider. Am I wrong?
[21:58] <thumper> aaronfc: yes
[21:59] <thumper> aaronfc: there is a way to manually bootstrap juju to an environment you have ssh access to
[21:59] <thumper> it is still very much beta
[21:59] <thumper> but workable
[21:59] <thumper> ish
[22:00] <aaronfc> I found juju yesterday and I thought giving a try on my brand new VPS :)
[22:00] <context> emphisis on the "ISH" ;)
[22:00] <context> i was able to use juju-local without much problems on vmware-fusion locally no problem
[22:00] <thumper> local is really targetted for devs to use on their own computers
[22:00] <aaronfc> log file does not exist
[22:01] <thumper> arosales: what about with a .gz?
[22:01] <aaronfc> in my case which would be the better choice ?
[22:01] <context> but i was running 13.10
[22:01] <aaronfc> (I do not have any cloud provider and I do not have the money to get one)
[22:01]  * thumper nods
[22:01] <thumper> this is one of the main use cases we had for the manual provisioning and manual bootstrap
[22:01]  * arosales assumes that ping was for aaronfc
[22:02] <aaronfc> any references for manual provisioning on juju ?
[22:02] <aaronfc> (and the manual bootstrap)
[22:03]  * thumper wonders where the docs are
[22:04] <marcoceppi> thumper: they won't land until the feature is complete
[22:04] <thumper> marcoceppi: I was checking the juju help topics
[22:04] <marcoceppi> thumper: oh that's on you guys
[22:04] <thumper> but they aren't there either
[22:04] <thumper> aaronfc: ping axw when he comes on line :-)
[22:04] <aaronfc> should I wait for a more usable version ?
[22:04] <thumper> depends how daring you are
[22:05] <aaronfc> just the right amount
[22:05] <aaronfc> haha
[22:09] <aaronfc> seems relatively difficult to get it work (couldn't find anything interesting on google :( )
[22:10] <aaronfc> do you guys know any alternative?
[22:17] <thumper> if you want to use juju, then manually bootstrapping is the only way to work in an unsupported cloud / non-cloud machine
[22:17] <webbrandon> aaronfc: You could also use AWS free tier for now if you have to much trouble with those methods(untill they are complete)  Just be sure to launch a micro instance.
[22:17] <webbrandon> you have 775 free hours of micro instance use
[22:18] <webbrandon> adds up quick when you have several instances going
[22:20] <aaronfc> thumper, can you develop a little more the "manually bootstrapping" ?
[22:20] <marcoceppi> webbrandon: if you like having your computer cycles stolen from you
[22:20] <aaronfc> It sounds like what I require, but can't find any info in how to do that
[22:20] <marcoceppi> ;)
[22:21] <aaronfc> webbrandon, thanks for the info :)
[22:21] <thumper> aaronfc: I've not done it myself, but I know the guy that wrote it
[22:21] <thumper> aaronfc: ask a question on 'ask ubuntu', tag with juju, and I'll get him to answer
[22:23] <webbrandon> marcoceppi: I know thats what sucks, but not a bad option for testing when your the only one accessing the instance
[22:26] <webbrandon> aaronfc: First part of this vid will show you how to get basic AWS setup(http://www.youtube.com/watch?v=vV8KYbFUcQw) Also this is the juju doc (https://juju.ubuntu.com/docs/config-aws.html) And this is how you launch a micro instance (juju bootstrap --constraints "cpu-power=0 cpu-power=0 mem=512M")
[22:28] <aaronfc> webbrandon, really appreciate your help :)
[22:28] <aaronfc> I will write all this down in case I finally can not get Juju to work locally :)
[22:29] <marcoceppi> aaronfc: everything is logged at http://irclogs.ubuntu.com/2013/11/06/%23juju.html
[22:29] <marcoceppi> updated every hour
[22:32] <aaronfc> hahahaha
[22:32] <aaronfc> nice to know
[22:32] <aaronfc> Hi Obama, how are you?
[22:34] <webbrandon> lol
[22:35] <webbrandon> whats out for thumper if you start talking about politics!!
[22:35]  * thumper squints at webbrandon
[22:39] <aaronfc> It's a pitty :( I'm really disappointed
[22:39] <aaronfc> I really wanted to install Juju! :( (I'm like a kid now, I know haha)
[22:40] <aaronfc> question about a new approach
[22:41] <aaronfc> is there any possibility to get my VPS being handled by my local computer? I mean, installing Juju on my machine (MAC) and configure it to handle my VPS as a cloud-provider ?
[22:43] <marcoceppi> aaronfc: that's more or less manual provider
[22:43] <marcoceppi> if you do proper port forwarding, I think you can do a local deployment then use juju add-machine to inlist servers outside via SSH
[22:43] <marcoceppi> aaronfc: what OS are you running now?
[22:44] <aaronfc> on my local machine ?
[22:44] <marcoceppi> yeah
[22:44] <aaronfc> OSX Maverick (I do not know how to spell it, the last one)
[22:44] <marcoceppi> aaronfc: there's a Vagrant box laying around somewhere that you can use to spin up an Ubuntu VM with the local provider configured and deployed
[22:45] <marcoceppi> so you can play with juju without needing to pay for an external source
[22:45] <marcoceppi> thumper: I haven't seen an announcement yet, but was that local provider snafu fixed/released in 1.16.3?
[22:45] <thumper> marcoceppi: should be
[22:45] <thumper> is it out?
[22:45] <marcoceppi> no idea
[22:46]  * marcoceppi checks the ppa
[22:46] <thumper> :)
[22:46] <marcoceppi> no :(
[22:46] <aaronfc> marcoceppi, would this Vagrant box allow me to manage my VPS ?
[22:47] <marcoceppi> aaronfc: no, not really at least not in an easy or proven fashion
[22:47] <aaronfc> Oh :( this is really sad
[22:48] <aaronfc> do you guys think Juju will at some point work out of the box for managing local machine ?
[22:48] <marcoceppi> aaronfc: you can manage a local machine, you're trying to manage a remote machine one-off with juju
[22:48] <aaronfc> I guess it is juju-local what I'm looking for, but as you saw I couldn't get it to work
[22:48] <aaronfc> :/
[22:48] <marcoceppi> aaronfc: that's on the roadmap
[22:49] <aaronfc> I'm trying to manage a remote machine, from that remote machine
[22:49] <marcoceppi> aaronfc: juju-local is designed for development/testing of juju and charms locally on your machine, not on a remote machine. Manual provisioning is what you want and it's due to land soon in Juju
[22:49] <aaronfc> I mean, I sshed on my VPS, and tried there to install juju-local
[22:49] <aaronfc> ok
[22:49] <aaronfc> now I understood :)
[22:50] <aaronfc> do you have any expected date ?
[22:50] <marcoceppi> aaronfc: right, that's not how juju works. It works better when you install juju on MacOSX from Homebrew, then bootstrap/manage a remote cloud
[22:50] <aaronfc> or anywhere  I could "subscribe" to know ?
[22:50] <marcoceppi> aaronfc: sign up for our mailing list to follow release announcements and discussions of juju features https://lists.ubuntu.com/mailman/listinfo/juju
[22:50] <aaronfc> ok, thanks
[22:51] <aaronfc> marcoceppi, I gess installing on MacOSX would work
[22:51] <marcoceppi> aaronfc: there's preliminary support already, but it's not documented and doesn't quite work yet, I suspect 1.17.0 will address a lot of the outstanding issues
[22:51] <jason955> Say I want to deploy some static HTML and possibly some PHP.  How would I go about doing that with Juju?  I figured I could just use Apache but don't know how to load the files into the charm.  It seems so straightforward but I can't figure out the correct way to do this.  Am I overthinking this?
[22:51] <aaronfc> but right now (and correct me if I'm wrong please) there is not easy way to manage a remote machine (by ssh)
[22:51] <aaronfc> I need a cloud provider
[22:52] <aaronfc> a VPS is not valid
[22:52] <marcoceppi> aaronfc: right, juju currently works best with a cloud provider. However, we're building a manual provider (in the works) that will allow you to manage one or more VPS machines/servers with Juju
[22:54] <aaronfc> that's awesome
[22:54] <aaronfc> then I will drop Juju for a while until it gets that manual provider :D
[22:54] <aaronfc> I'll suscribe to the mailing list you sent before
[22:54] <aaronfc> thank you all so much :)
[22:55] <marcoceppi> aaronfc: sure, feel free to post asking about the manual provider, etc. A lot of juju people are here, but we're spread out around the world. Mailing list/askubuntu is a great place to have a longer running discussion
[22:58] <jason955> Say I want to deploy some static HTML and possibly some PHP.  How would I go about doing that with Juju?  I figured I could just use Apache but don't know how to load the files into the charm.  It seems so straightforward but I can't figure out the correct way to do this.  Am I overthinking this?
[23:03] <marcoceppi> jason955: so, there is no real generic "php" charm. You'd need to write a charm for that particular set of php code
[23:38] <jason955> marcoceppi: thanks.  How about html? Same story?
[23:38] <marcoceppi> jason955: HTML should be easier, let me check the charm
[23:38] <jason955> marcoceppi: thanks!
[23:41] <jason955> I'm just trying to grasp the Juju concepts here.  I really like the idea and would like to contribute if I can.  Do you guys need any help on the project?  I can write docs.  I can code in Python.  I know a little bit of bash.  I understand design patterns.
[23:48] <marcoceppi> jason955: we need docs, we need charms!
[23:48] <jason955> marcoceppi: it looks like the LAMP charm will pull from a repo
[23:48] <marcoceppi> jason955: yes, I was about to mention that as an alternaive
[23:48] <marcoceppi> the apache2 charm is really more like a loadbalancer/routing charm
[23:48] <jason955> How do I get started?  Sign up on to launchpad?
[23:48] <jason955> gotcha
[23:49] <marcoceppi> jason955: yeah, grab a launchpad account, it's free. Then check out http://juju.ubuntu.com/docs for information about charm authors
[23:50] <marcoceppi> jason955: there's a tool not mentioned on the writing a charm section yet, called charm-tools, I recommend installilng it and running `juju charm create` to get a basic template for a charm, then reading the charm author docs
[23:51] <jason955> awesome.  Thanks.  I've read most of the docs.  I will check out the charm-tools software.
[23:51] <sarnold> strongly recommended, it'll save some time and effort and beats hand-copying from the docs :) hehe
[23:51] <jason955> thanks!
[23:52] <marcoceppi> jason955: if you're on Ubuntu, you can `sudo add-apt-repository ppa:juju/stable` then apt-get update apt-get install charm-tools; there's an MSI for Windows and you can pip install charm-tools for Mac OSX
[23:52] <jason955> I saw there is a Nginx charm but the development has stopped.  How can I get the source from where the author left off?
[23:53] <marcoceppi> jason955: once you have Bazaar and Launchpad you can run bzr branch against the code branch for it
[23:53] <jason955> marcoceppi: thanks.  I will be sure to DL the tool.
[23:53] <jason955> I've used git and hg before so I need to learn a bit about bzr
[23:53] <marcoceppi> jason955: if you're referring to this one, then the branch is the second URL listed: http://manage.jujucharms.com/~imbrandon/precise/nginx
[23:54] <webbrandon> the first time using bzr may be a pain but once you get it going it is a cinch
[23:54] <marcoceppi> jason955: it's very similar to both, it's a DVCS tool, you bzr add, bzr commit, bzr push, etc. Only difference is you don't clone you "branch". Branches in bazaar (unlike git) are hosted externally
[23:55] <marcoceppi> so each repo is a branch
[23:55] <jason955> got it.  I'll read some tutorials but sounds pretty similar to what I'm used to.
[23:56]  * marcoceppi nods, feel free to ping in here if you need any help
[23:56] <jason955> thanks for your help.  I look forward to contributing.
[23:57] <marcoceppi> jason955: no, thank you! feel free to record any feedback about our docs and post them to the mailing list. Having users provide feedback on how we can improve is much apprecaited


[19:27] <mrand> B-sides austin, next month for all you security interested guys.  I'll most likely be there.
[19:27] <mrand> I'm not really a security guy (although it interests me)... I'm just there as a crash test dummy.
[19:27] <mrand> for a guy that is giving a talk.


[07:05] <lordievader> Good morning.
[07:12] <elfy> morning lordievader
[07:13] <lordievader> Hey elfy, how are you?
[07:13] <elfy> awake just :)
[07:14] <elfy> and just realised it's work in 15 minutes and not 30 ...
[07:14] <lordievader> Ouch.
[09:03] <Dreaman> :)
[09:04] <Dreaman> os[Linux 3.16.0-22-generic x86_64] distro[Ubuntu "utopic" 14.10] cpu[2 x AMD Athlon(tm) 7750 Dual-Core Processor (AuthenticAMD) @ 2.70GHz] mem[Physical: 3.9GB, 76.9% free] disk[Total: 228.5GB, 43.5% free] video[Advanced Micro Devices, Inc. [AMD/ATI] RV790 [Radeon HD 4890]] ether[NVIDIA Corporation MCP77 Ethernet] sound[HDA-Intel - HDA NVidia1: HDA-Intel - HDA ATI HDMI]
[09:04] <Dreaman> sleeping o yea
[09:07] <vitimiti> Hi
[09:27] <Dreaman> http://s23.postimg.org/8brbactp7/Screenshot_from_2014_10_15_12_22_50.png
[09:33] <Dreaman> http://s27.postimg.org/bbsb0bkk3/Screenshot_from_2014_10_15_12_32_10.png
[09:33] <Dreaman> :)
[17:18] <BluesKaj> Hi all
[17:50] <jtaylor> grr compiz crash #237
[17:50] <jtaylor> at least the autorestart is reliable
[21:36] <vitimiti> Hi
[22:51]  * vitimiti Bye
[23:01] <Joro_> hello
[23:02] <Joro_> I get this message on update:
[23:02] <Joro_> Errors were encountered while processing:
[23:02] <Joro_>  syslinux-themes-debian
[23:02] <Joro_> E: Sub-process /usr/bin/dpkg returned an error code (1)
[23:03] <Joro_> anyone with help?
[23:04] <sage__> is the 14.10 release candidate ready for download yet? I know that it was due today.
[23:04] <bubbasaures> https://wiki.ubuntu.com/UtopicUnicorn/ReleaseSchedule
[23:05] <sage__> Yes, I see that, and by that schedule, there should be a release candidate, but I haven't found it online anywhere.
[23:06] <bubbasaures> 10/15 here and when released it has to populate the ubuntu servers
[23:06] <ObrienDave> sage__, 2100 UTC tomorrow
[23:07] <sage__> okay, thanks
[23:07] <jtaylor> rc time already?
[23:07] <jtaylor> need to debug my touchpad stopped working issue then quickly ...
[23:08] <jtaylor> (in last kernel update)
[23:08] <bubbasaures> Ubuntu, we do the thinking for you.
[23:33] <jtaylor> hi, utopic kernel .29 broke the left touchpad button on my lenovo g50
[23:34] <jtaylor> verified the issue is present in mainline >= 16.4 up to 17.1 but not 16.3
[23:34] <jtaylor> ups wrong channel ...


[12:57] <tjaalton> alioth (git.d.o) down
[14:11] <mdeslaur> I'm preparing a security fix for CVE-2011-4613 in xorg. Debian fixed the issue by backing out a change that we added for starting X directly from within upstart wihout using a display manager.
[14:11] <ubot4`> mdeslaur: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4613)
[14:11] <mdeslaur> Is anyone aware of anything that actually uses that that could get regressions from that update?
[14:11] <mdeslaur> bryce: ^
[14:12] <mdeslaur> (fyi, this is the CVE: http://www.debian.org/security/2011/dsa-2364)
[14:14] <tjaalton> meh, git.d.o is down, can't check what the change was
[14:15] <jcristau> i'm not, fwiw
[14:15] <mdeslaur> tjaalton: basically this: http://paste.ubuntu.com/807415/
[14:15] <mdeslaur> jcristau: hi!
[14:16] <jcristau> hi mdeslaur
[14:16] <mdeslaur> jcristau: I can't seem to locate anybody who remembers the exact reason we had added that change in the first place :P
[14:17] <jcristau> i talked to lool when i did the revert
[14:17] <jcristau> he agreed it was the right thing to do
[14:17] <mdeslaur> yeah, I talked to him too, and he can't recall the exact use case
[14:17] <jcristau> ok :)
[14:18] <mdeslaur> I agree it's the right thing to do, I'm just trying to figure out what the use case was that I will be breaking :P
[14:18] <mdeslaur> all I can think of that wouldn't use a display manager would be some oem project, maybe unity light or something
[14:19] <tjaalton> that was over three years ago
[14:19] <tjaalton> well before unity
[14:19] <tjaalton> ah right
[14:19] <tjaalton> oem
[14:19] <mdeslaur> whoops, I meant ubuntu light
[14:19] <tjaalton> yeah
[14:39] <lool> mdeslaur: I think this predates ubuntu light, but it might have been in some moblin / maemo / moblin 2 / meego based projects ; albeit I suspect none of them shipped, but ICBW
[14:39] <lool> it's hard to tell whether some hacks might have been used at a later date or not
[14:40] <mdeslaur> lool: hi! well, in theory the oem stuff should vet updates before they are pushed, so I'll just put them in -proposed for a week or two and make sure nothing terrible happens
[14:40] <lool> mdeslaur: I think that's fair
[14:40] <mdeslaur> lool: thanks
[14:40] <lool> mdeslaur: Also, I believe OEM is not pulling updates which concern only local root exploits on single-user devices such as netbooks
[14:43] <mdeslaur> lool: don't say stuff like that, you make me sad :)
[14:44] <lool> oh sorry
[14:46] <jcristau> because clearly there's never any code execution flaw in, say, browsers, that would turn a local root into a remote root
[14:47]  * jcristau hides
[14:47] <tjaalton> :)
[15:54] <seb128> tjaalton, libwacom has a new upstream tarball btw if you want to do the update while you fix the copyright and reupload ;-)
[15:58] <tjaalton> seb128: yeah I noticed that it got rejected
[16:55] <tjaalton> seb128: are you planning on putting the new g-c-c in precise?
[16:56] <seb128> tjaalton, no
[16:56] <seb128> why?
[16:56] <tjaalton> just wondering why the interest in libwacom :)
[16:57] <seb128> it helps for those of us who work on GNOME patches and want to build g-c-c from git
[16:57] <tjaalton> ok
[16:57] <tjaalton> hmm, can't seem to work out a watch file for it
[16:57] <seb128> we don't need to jhbuild or do a git build of libwacom
[16:58] <seb128> just copy any GNOME one?
[16:58] <seb128> i.e
[16:58] <seb128> version=3
[16:58] <seb128> http://ftp.gnome.org/pub/GNOME/sources/libwacom/([\d\.]+[02468])/ \
[16:58] <seb128>         libwacom-(.*)\.tar\.xz
[16:58] <seb128> ?
[16:58] <tjaalton> it's hosted on sourceforge..
[16:58] <tjaalton> as a subdir on linuxwacom
[16:59] <seb128> well
[16:59] <seb128> http://ftp.acc.umu.se/pub/GNOME/sources/libwacom/
[16:59] <seb128> it's mirrored there then, track the GNOME side?
[16:59] <tjaalton> .xz
[16:59] <tjaalton> do we support that yet?
[16:59] <tjaalton> sourceforge has only .bz2
[16:59] <seb128> yes, since oneiric at least
[16:59] <seb128> GNOME does .xz only since this cycle
[17:00] <tjaalton> ok
[17:00] <jcristau> tjaalton: "http://sf.net/linuxwacom/ libwacom-(.*)\.tar.gz" doesn't work?
[17:00] <jcristau> s/gz/bz2/
[17:01] <tjaalton> nope
[17:01] <tjaalton> with or without the space :)
[17:02] <jcristau> hmm. http://qa.debian.org/watch/sf.php/linuxwacom/ has a libwacom tarball, but maybe it's ood
[17:02] <tjaalton> yeah, it is
[17:03] <tjaalton> oh well, I'll see what the status is tomorrow, maybe even alioth is up again :)
[17:03] <tjaalton> ah, is already
[17:04] <jcristau> yep, came back up a few minutes ago
[17:05] <tjaalton> that's nice
[17:06] <tjaalton> seb128: I'll have it done tomorrow, just the copyright left to fix
[17:12] <seb128> tjaalton, thanks
[20:23] <bhearsum> i filed a bug about automatic detection not working properly (https://bugs.launchpad.net/ubuntu/+source/gnome-desktop3/+bug/888134) a couple of months ago. i just now figured out that it's a problem with either only with awesomewm, or with all non-unity/gnome ones - i'm not really sure what else to do to try and debug it, or find a fix - is there anyone that can point me in the right direction?
[20:23] <ubot4`> Launchpad bug 888134 in gnome-desktop3 (Ubuntu) "automatic detection of plugged in / removed monitor is too aggressive (affects: 1) (heat: 6)" [High,Incomplete]
[20:34] <bryce> mdeslaur, right that's the old mid stuff
[20:34] <mdeslaur> bryce: ok, so nothing to worry about?
[20:34] <bryce> mdeslaur, they used to launch ubuntu on those devices using a startx type script rather than a display manager
[20:35] <bryce> mdeslaur, let me dig up some background info just to fill in all the details but yeah I'm sure that's utterly obsolete by now
[20:36] <bryce> mdeslaur, http://irclogs.ubuntu.com/2008/09/08/%23ubuntu-devel.txt start around 10:47
[20:36] <bryce> mdeslaur, that was one of the hacks to get poulsbo working
[20:37] <mdeslaur> bryce: awesome, old stuff...thanks!
[20:37] <bryce> mdeslaur, which we no longer maintain in the distro, so I believe it can be killed with fire with no prob.
[20:41] <mdeslaur> cool
[20:43] <tjaalton> mdeslaur: for precise, we could just merge xorg
[20:44] <tjaalton> ?
[20:46] <mdeslaur> tjaalton: yeah, that sounds good
[20:47] <tjaalton> mdeslaur: ok, I could prepare that tomorrow if that's fine
[20:48] <mdeslaur> tjaalton: that wouldbe awesome, thanks!
[20:52] <tjaalton> hmm actually, I'll check it the staging ppa already has it
[21:02] <tjaalton> nope
[21:03] <tjaalton> maybe this should be uploaded there first
[22:29] <cnd> RAOF, I *think* all the input-related stuff is in ppa:canonical-x/x-staging
[22:30] <cnd> in the email I sent out, I mentioned having to rebuild utouch-grail, but that isn't the case
[22:30] <cnd> I also added the breaks clause for xorg-server myself
[22:30] <cnd> so now it just needs all the other bits that you can upload (and for the build queue to fall down so something will actually build)
[22:33] <RAOF> cnd: Awesome.
[22:34] <cnd> RAOF, we may be able to do a syncpackage for libxi and libx11
[22:34] <cnd> I haven't looked into it
[22:34] <RAOF> From Debian?  I'll check.
[22:35] <cnd> the bug there is that we have x11proto-input-dev <IP_ADDRESS>.really.2.0.2-0ubuntu1
[22:35] <cnd> and most of the debian libs depend on >= <IP_ADDRESS>
[22:35] <cnd> so if we want to sync with debian, we need to bump the depends in debian :(
[22:35] <cnd> to x11proto-input-dev >= <IP_ADDRESS>
[22:36] <cnd> I'm going to switch to upstream synaptics multitouch work now
[22:36] <RAOF> Cool.
[22:36] <RAOF> I can take it from here.
[22:37] <RAOF> Ah, we've even got the Qt in there.
[22:37] <RAOF> Magnificent.
[22:38] <RAOF> Heh.  1 package building: qt4, armhf.
[22:38] <RAOF> I guess that buildd will be ready to do something else tomorrow :)
[22:47] <bryce> the buildd's seem slow again today
[22:47] <bryce> (at least for ppas)
[22:48] <RAOF> armhf is motoring along.
[22:49] <RAOF> But that would be becuase general PPAs don't get to build on arm :)
[22:52] <cnd> RAOF, and on top of that, armhf is new and I had to specifically ask for it
[22:52] <cnd> there's probably only two or three PPAs with armhf turned on :)
[22:52] <RAOF> Do we need to build for both armel and armhf, or just armhf?
[22:53] <cnd> RAOF, it's covered in ubuntu-devel, but they aren't sure yet if they want to support armhf or armel for the LTS yet
[22:53] <cnd> ogra insisted we build for armhf
[22:54] <RAOF> Yeah, I saw he wanted us to additionally build armhf.  The PPA is only building armhf, though.
[22:55] <cnd> oh, hrmph
[22:55] <cnd> let me ping the lp folks again
[22:55] <RAOF> Ah, there's more to that thread I haven't read yet.
[23:13] <Sarvatt> cnd: the upload all at once and let depwait fix it really fails in PPAs where we dont have auto retries for depwait, they need manual retries that are automatically at the end of the build queue and scored lower
[23:13] <Sarvatt> makes lots of sense to upload protos, wait for published, repeat for libs then server then driver
[23:14] <Sarvatt> s
[23:14] <Sarvatt> with the bonus that build depends dont matter that way :P
[23:15] <cnd> Sarvatt, I planned on watching the ppas and retrying :)
[23:16] <Sarvatt> they go to the end of a 9 hour queue with a retry, at least new uploads are scored a bit higher :(
[23:16] <Sarvatt> heck maybe we should make the ppa private for a bit, then it'd get like +10000 build score and skip the queues :)
[23:17] <bryce> heh
[23:18] <cnd> they were going to make it private, but I didn't like the idea of a private ppa for ubuntu-specific content
[23:19] <Sarvatt> cnd: this stuff is going to be copied into ubuntu right?
[23:19] <cnd> yeah
[23:19] <cnd> RAOF, all the arches should be turned on now
[23:19] <Sarvatt> xserver-xorg-input-synaptics	 1.5.0+git20120101-1ubuntu1~nomt3
[23:19] <Sarvatt> ~nomt3?
[23:20] <cnd> Sarvatt, that ~nomt3 was meant to be temporary, it probably will be whacked off
[23:20] <cnd> the initial X upload may be without the multitouch on trackpads
[23:20] <cnd> cause I'm working on that right now :)
[23:21] <RAOF> I don't mind having a ~nomt upload to the archive.  But given the PPA queue you'll probably have a fair amount of time to work on synaptics MT before it's an issue :)
[23:23] <Sarvatt> multitouch seems to be working with 1.12 and synaptics from git with debian's debian/
[23:24] <Sarvatt>     Event code 334 (BTN_TOOL_TRIPLETAP)
[23:24] <Sarvatt>     Event code 335 (BTN_TOOL_QUADTAP)
[23:24]  * Sarvatt tries to figure out how to really test it
[23:29] <cnd> Sarvatt, that's not multitouch :)
[23:29] <cnd> that's multifinger
[23:45] <Sarvatt> 4 finger taps were supported before?
[23:48] <Sarvatt> yeah http://cgit.freedesktop.org/~whot/multitouch agrees on the no multitouch aspect :P
[23:53] <Sarvatt> RAOF: wow, 2 nights in hotels between flights?
[23:54] <RAOF> Yup.
[23:54] <RAOF> It was awesome.
[23:59] <bryce> RAOF, did they let you have your luggage?


[20:10] <airurando> evening
[20:12] <zmoylan-len> hi
[20:12] <zmoylan-len> tis a quiet one
[20:14] <airurando> has been for a while zmoylan-len
[20:14] <airurando> how are you keeping?
[20:14] <zmoylan-len> well folks are coming back from holiday and have more time as those covering them are less busy
[20:15] <zmoylan-len> august is always a quiet time.  even the news is usually quiet
[20:15] <airurando> aye
[20:16] <airurando> can't catch tdr112 at all
[20:16] <zmoylan-len> czajkowski is supposedly over in sept
[20:17] <airurando> heard that. hope to meet up>
[20:19] <airurando> zmoylan-len: are you about on 14 Sep 13?  UGJ in TOG I think.
[20:21] <zmoylan-len> suspect not.  travel is still... variable.  am trying increasinly to extend range but i overshot last meetup and failed :-(
[20:22] <zmoylan-len> will see closer to the day
[20:24] <zmoylan-len> ah, saturday. suspect i'll be at rpg game that day.  travel is easier as i get lift. it's 50-50
[20:26] <czajkowski> I am
[20:26] <czajkowski> I am over from 23-26th
[20:26] <czajkowski> I'm free on the 23rd
[20:26] <czajkowski> gonna send a mail out
[20:30] <zmoylan-len> what is needed hardware wise and software wise for ugj?  if i can prepare it might make me try harder to get there if i've already got bits sorted out
[20:31] <czajkowski> zmoylan-len: laptop or something to testing on
[20:31] <czajkowski> and the latest iso of what you want to test
[20:32] <zmoylan-len> and will the ugj in tog be targetting a specific piece of software?
[20:32] <zmoylan-len> just wondering
[20:32] <zmoylan-len> sorry if questions sound dumb
[20:49] <czajkowski> zmoylan-len: no not specific
[20:49] <czajkowski> so you can test your drivers on the release
[20:49] <zmoylan-len> okie dokie.
[20:49] <czajkowski> your machine working
[20:51] <zmoylan-len> if i make it there, want to be useful


[09:08] <sil2100> jibel: hey! How's the xenial dailies testing going? How bad is it? ;)
[09:09] <cpaelzer> hi, I happened to hear that one can retrigger autopkgtests but group packages
[09:09] <cpaelzer> like retry test on A, but only with this version of B
[09:09] <cpaelzer> I need just that to resolve bug 1748135 that I just analyzed
[09:10] <cpaelzer> does anybody have link to a howto, scripts, or anything that I can use to learn how that is done?
[09:21] <cpaelzer> pitti: sorry to bother, but you might know the answer to above ^^
[09:23] <pitti> cpaelzer: yes, that can be done with specifying a set of "triggers" with appropriate versions; like, test package A with these three versions from -proposed
[09:24] <pitti> https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Test_request_format describes the syntax
[09:25] <pitti> cpaelzer: https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Re-running_tests gives the CLI for run-autopkgtest, but I think this is obsolete (nobody should have access to snakefruit any more)
[09:26] <pitti> cpaelzer: but if you have a typical retry URL, you can just  append more &trigger=srcpkg/version arguments if you want to run it against more packages from -proposed
[09:27] <cpaelzer> pitti: thanks, I'd construct one of those and ask you to review if that is ok
[09:27] <cpaelzer> back in a few minutes
[09:27] <pitti> sounds good
[09:31] <cpaelzer> pitti: http://paste.ubuntu.com/26540222/ ok ?
[09:34] <pitti> cpaelzer: LGTM! (corresponds to http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#vagrant)
[09:35] <cpaelzer> thanks pitti!
[09:36] <cpaelzer> I used an urlencoder actually and not copied from #vagrant, but as long as it works it is fine :-)
[09:55] <pitti> cpaelzer: I meant I compared the version number
[09:56] <cpaelzer> yeah I relaized that you did check there how the trigger for vagrant was
[09:57] <cpaelzer> I just meant I didn't copy from there, but instead used an encoder to get the appendix needed
[09:57] <cpaelzer> in any case it seems to work, which was the important part :-)
[09:57] <pitti> 👍
[09:58] <cpaelzer> death by UTF
[09:59] <pitti> cpaelzer: since these appear in full color and nicely rendered in plain terminals, I just like them even more
[09:59] <pitti> that started in Fedora 27, supposedly there's a newer font; (haven't tried in Ubuntu yet)
[10:13] <ginggs> tseliot: do you have an ETA for nvidia-graphics-drivers-390 ?
[10:18] <tseliot> ginggs: in the next few days, at least in 18.04
[10:20] <doko> xnox: we will have openssl1.0 for a while now? promote it? and subscribe foundations?
[10:20] <tseliot> ginggs: it's going to be available in a PPA first, together with glvnd enabled mesa
[10:21] <ginggs> tseliot: thanks, please don't forget to add libcuda-9.1-1 - needed for cuda 9.1 in debian experimental
[10:22] <tseliot> ginggs: done
[10:22] <ginggs> tseliot: ta!
[10:24] <tseliot> thanks for reminding me ;)
[11:37] <xnox> doko, yes, foundations should be subscribed; looking at componenets-mismatches, i am confused why only the udeb shows up without the main library.
[11:37]  * xnox subscribes things
[11:39] <xnox> doko, foundations bugs subscribed
[11:53] <doko> jamespage: pysmi and pycryptodome need a MIR (dep of python-snmp4, openstack subscribed)
[12:06] <jamespage> doko: ta - either coreycb or I will pick that up
[12:07] <ginggs> tseliot: please ping me when it's in the PPA, I have a machine with two Titan X cards ready for testing!
[12:32] <jbicha> pitti: color emoji works in Ubuntu 18.04 but not 17.10
[12:32] <jbicha> it works in Debian GNOME Testing too
[12:33] <jbicha> pitti : is it possible to push https://launchpad.net/ubuntu/+source/gvfs/1.20.1-1ubuntu3 to Debian?
[12:45] <doko> xnox: did you find out where the -m64 on arm64 comes from?
[12:48] <pitti> jbicha: not necessarily; Debian's LXC containers likely don't have sudo installed or configured
[12:49] <pitti> the test could start out as root, depend on sudo, create a user, and drop privs maybe
[12:49] <pitti> but this has always been a bit awkward
[12:51] <jbicha> pitti: for ci.debian.net, it already has "SKIP Test requires machine-level isolation but testbed does not provide that"
[12:53] <pitti> jbicha: ah, I see; it would still not work when running it with qemu against a bootstrapped VM, but then again maybe the current debian test version also doesn't
[12:53] <pitti> so if that's the only remaining delta, I guess it doesn't hurt much to  commit that to debian
[12:56] <jbicha> we have two MIRs we need too, at least the libnfs MIR would be nice to simplify allowing us to sync from Debian
[12:56] <jbicha> if you have any idea about how the "create a user and drop privs" thing would work, that would be nice
[12:57] <jbicha> but I guess there aren't many people in Debian running autopkgtests besides ci.debian.net
[12:57] <pitti> (meeting, TTYL)
[13:17] <cpaelzer> xnox: the nova autopkgtest is resolved, I kicked the one from the openssl upload again
[13:33] <tseliot> ginggs: I will, thanks
[13:39] <xnox> doko, no, not yet, will do.
[13:40] <doko> xnox: if it was in kamailio, it's now fixed
[13:41] <xnox> doko, yes, as that is part of ssl1.1 transition, green on all other arches. thanks!
[13:47] <doko> seb128, didrocks, jbicha: how takes care about DX Packages, or Ubuntu Touch seeded packages these days? jbicha renamed d-conf to dconf, and it needs a new bug subscriber
[13:47] <doko> who even ...
[13:49] <seb128> doko, that's a desktop GNOME upstream package
[13:50] <seb128> nothing to do with dx or touch
[13:50] <seb128> but good point, we should unsubscribe ourselve from those if we are subscribe to any
[13:51] <seb128> doko, I subscribed desktop-packages to dconf now, thanks for pointing it out
[13:56] <doko> ta
[14:09] <doko> jbicha: gtk-doc still ftbfs
[14:16] <jbicha> doko: yes, I don't know how to fix gtk-doc
[14:17] <doko> :-/
[14:26] <seb128> doko, btw could you give another look to the libblockdev MIR, jbicha addressed your comments and it's blocked the udisks update which is blocking other things
[14:34] <doko> seb128: ok
[14:36] <seb128> doko, thanks
[14:37] <seb128> doko, also any idea if something is not set up right on https://bugs.launchpad.net/ubuntu/+source/chrome-gnome-shell/+bug/1695565 , it has been sitting there since june, I know the MIR team is busy but that looks like it's too long and I wonder if it's not showing up on the review list for some reason?
[14:46] <dgadomski> hey seb128, fyi fix for bug #1644662 has been upstreamed, I've attached debdiffs with fixes for xenial-bionic
[14:47] <seb128> dgadomski, yeah, nice, thanks
[14:47] <seb128> I'm going to try to have a look
[15:06] <pitti> jbicha: "there aren't many people in Debian running autopkgtests besides ci.d.n"> agreed, so commiting that wouldn't hurt too much
[15:06] <pitti> and it's a rather nasty hack anyway - the test needs to set up something as root, but wants to run as user, and makes assumptions about sudo working (without password)
[16:07] <doko> why are the python-gnupg tests hang on the buildds?  succeed locally
[16:10] <seb128> hum, dpkg/bionic changed in a way that makes pkgbinarymangler tests unhappy
[16:20] <seb128> ""no entry control.tar.gz in archive" hum
[17:41] <smoser> ok... i'm trying to come up with the url to a .dsc file for a specific version of a source package.
[17:43] <smoser> easiest way to get that ?
[17:46] <rbasak> Go via "Publishing History"?
[17:46] <rbasak> Or you mean automatically by API?
[18:09] <smoser> rbasak: well, i was  meaning just through apt
[18:10] <rbasak> I wonder if apt-get source foo=version works
[18:11] <rbasak> Another might be to run chdist against /var/lib/apt/lists/something, but that is perhaps not using apt depending on your definition :)
[18:11] <smoser> well, it would
[18:11] <smoser> here. i'll describe :)
[18:11] <rbasak> I'm pretty confident that the chdist would work
[18:11] <rbasak> Ah
[18:11] <rbasak> I mean
[18:11] <rbasak> Uh
[18:11] <rbasak> chdist?
[18:11] <rbasak> I mean grep-dctrl
[18:12] <xevious_> PHP dependencies are currently questionable in Bionic: `php-cli` pulls in PHP 7.1, but `php-xdebug` pulls in PHP 7.1.
[18:12] <xevious_> hah
[18:12] <xevious_> oops
[18:12] <xevious_> Typo, clearly.
[18:12] <rbasak> A PHP transition is still in progress.
[18:12] <xevious_> Correction: PHP dependencies are currently questionable in Bionic: `php-cli` pulls in PHP 7.1, but `php-xdebug` pulls in PHP 7.2.
[18:12] <smoser> grep-dctrl, maybe helpful.
[18:13] <xevious_> rbasak: Is there a page or mailing list discussion that outlines the transition?
[18:13] <xevious_> Also, is there anything I can do to help with the transition?
[18:15] <rbasak> http://people.canonical.com/~ubuntu-archive/transitions/html/php7.2.html lists it as done, but I suspect that's only to -proposed rather than landed in the release pocket.
[18:15] <rbasak> nacc has been working on the transition, but he's out until Monday now I think.
[18:15] <rbasak> I wouldn't want to step on his toes.
[18:16] <xevious_> Of course.
[18:18] <xevious> Hopefully we can chat about it more on Monday when he's back. If there's any work that can be split up, I'm able to help and can rally at least one more.
[18:18] <rbasak> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php-defaults is how it currently looks.
[18:18] <rbasak> There are probably other packages caught up in it as well.
[18:19] <rbasak> xevious: thank you for the offer. Let's see what nacc says on Monday (or feel free to ping him directly here)
[18:20] <smoser> rbasak: http://paste.ubuntu.com/26542394/
[18:21] <Pharaoh_Atem> rbasak: the php-libvirt-php import from Debian is crashing on php7.2
[18:21] <Pharaoh_Atem> which is weird, because in Fedora, my php-libvirt package built just fine with php7.2
[18:21] <Pharaoh_Atem> rbasak: that is, it's crashing on attempting to build against php7.2
[18:22] <Pharaoh_Atem> rbasak: has nacc been away for a while? I've been trying to get in touch with him...
[18:23] <rbasak> smoser: another approach I've seen done in quite a few packages is to generate another binary package for test purposes that contains what you need. Eg. "curtin-vmtest".
[18:24] <rbasak> That would depend on curtin. Then for your test run, just enable the PPA (or whatever your binary package source is) and install curtin-vmtest, and you have what you needed from the source tree.
[18:24] <smoser> rbasak: i had thought about that.
[18:24] <rbasak> Pharaoh_Atem: I'm not sure. He's got very little overlap with my timezone, so I tend not to notice.
[18:25] <Pharaoh_Atem> :/
[18:25] <smoser> that m ight be the easiest path forward.
[18:25] <smoser> or even just curtin-source
[18:26] <rbasak> smoser: reasons in favour: I've seen it done that way in various places; you don't have to rely on an out-of-band connection between the two things.
[18:26] <rbasak> A recent example I used is openscad-testing
[18:26] <rbasak> mysql has something similar too IIRC.
[18:27] <rbasak> I'm not so sure about curtin-source. A -test package has a specific user purpose. A -source package sounds like a corruption of what binary packages are meant to be.
[18:27] <rbasak> I accept there's not much difference :)
[18:27] <rbasak> OTOH you could in theory put packaging assistance into a -test package.
[18:27] <rbasak> (to run the test suite, etc)
[18:27] <smoser> yeah, -source just seemed a better name, because it is easier if i just grab all of source.
[18:27] <smoser> than try to pick out vmtest/ portion or something.
[18:28] <smoser> where woul dyou suggest it installing files to ?
[18:28] <rbasak> /usr/share/curtin-vmtest/
[18:29] <rbasak> Or /usr/share/curtin/vmtest/
[18:29] <rbasak> Assuming that they're not architecture-specific, etc.
[19:59] <jbicha> infinity: could you explain https://launchpad.net/ubuntu/+source/gvfs/1.34.1-1ubuntu3 ?
[21:04] <infinity> jbicha: Seems pretty self-explanatory?  /etc/init doesn't exist on all Ubuntu systems.
[21:09] <infinity> jbicha: It was fixing this<EMAIL_ADDRESS>[21:09] <infinity> jbicha: It would be failing in Debian the same way, except that Debian doesn't run the tests at all because they require isolation.
[21:19] <jbicha> ok, the file name was confusing though (upstart)
[21:19] <infinity> jbicha: Because "/etc/init" is a path specific to upstart.
[21:19] <infinity> jbicha: Hence that test started failing when we switched to systemd and removed upstart scripts from the testbed.
[22:05] <cjwatson> smoser: If you literally just want a URL, I thought I mentioned that on #launchpad the other day?  https://launchpad.net/~OWNER/+archive/ubuntu/PPANAME/+files/PACKAGE_VERSION.dsc always works as long as the source package hasn't been removed for long enough that it's been garbage-collected.
[22:07] <cjwatson> (lp.soyuz.browser.archive.ArchiveNavigation -> lp.services.librarian.browser.FileNavigationMixin -> lp.soyuz.model.archive.Archive.getFileByName)
[22:32] <smoser> cjwatson: well that works if i know it came from a ppa. but this doesnt  just test ppa. also tests proposed or archive.
[22:32] <smoser> so i wanted to find where it comes from and go off that.
[22:32] <smoser> https://code.launchpad.net/~smoser/curtin/+git/curtin/+merge/337388 is what i have