[00:17]  * Makyo is away: EoD
[00:36] <bodie_> oh that's annoying
[00:36] <bodie_> https://github.com/kapilt/juju-digitalocean requires manual deployment of VMs before you can put services on them
[00:36] <bodie_> doesn't that kinda defeat the purpose?
[00:37] <davecheney> bodie_: that is why it's called the 'manual' provider :)
[00:38] <bodie_> *mutters*
[00:39] <rick_h_> bodie_: heh, yea that's the advantage of using full providers
[00:39] <davecheney> call it a forcing function
[00:40] <bodie_> digitalocean just got $37M in funding.. maybe we should think about enhancing juju's interface with 'em at some point ;) they're trying to take on AWS
[00:41] <bodie_> really hits the price/performance sweet spot with all the extra fluff removed
[00:42] <bodie_> not that EC2 and S3 are fluff... but for a lot of people, the bells and whistles just complicate things
[00:42] <bodie_> just thinking out loud here :)
[00:43] <rick_h_> I'm sure others have pondered and sent an email or two :)
[00:56] <davecheney> bodie_: the ball is in their court, they need to provide an API
[00:56] <davecheney> and join the CPC program
[03:48] <jose> lazyPower: hey! around?
[03:48] <marcoceppi> jose: I think he's off for the evening
[03:49] <jose> marcoceppi: oh, I had a question (as he was the last to review the mailman charm)
[03:49] <jose> I'm about to do a push and wanted to see if someone could test it (local provider has some problems as you know)
[03:50] <marcoceppi> jose: I can try
[03:50] <jose> sure, I should push it in ~3m
[03:53] <jose> marcoceppi: mind trying the charm? config-changed was giving an error before, should be fixed now
[03:53] <marcoceppi> jose: linky link?
[03:53] <jose> https://bugs.launchpad.net/charms/+bug/1199052 and https://code.launchpad.net/~jose/charms/precise/mailman/trunk
[03:53] <_mup_> Bug #1199052: New charm: mailman <Juju Charms Collection:New> <https://launchpad.net/bugs/1199052>
[03:53] <jose> lp:~jose/charms/precise/mailman/trunk
[04:09] <jose> marcoceppi: any blockers found?
[04:09] <marcoceppi> jose: http://paste.ubuntu.com/7088242/
[04:10] <jose> marcoceppi: you know a way of using spot instances with juju? like, manually? I *may* be able to afford a couple to test
[04:11] <marcoceppi> jose: the manual provider can do that
[04:11] <marcoceppi> jose: what's wrong with local provider?
[04:11] <jose> last time I tried using there was a bug on LXC which prevented me from deploying
[04:11] <jose> I'm going to try again
[04:12] <jose> ERROR cannot find network interface "lxcbr0": net: no such interface // ERROR failure setting config: cannot find address of network-bridge: "lxcbr0" // ERROR cannot find address of network-bridge: "lxcbr0"
[04:12] <jose> marcoceppi: ^
[04:13] <marcoceppi> jose: sudo apt-get purge lxc juju-local
[04:13] <marcoceppi> sudo apt-get install juju-local
[04:13] <marcoceppi> see if that creates the lxcbro
[04:13]  * jose does
[04:15] <davecheney> ubuntu@winton-02:~/src/launchpad.net/juju-core$ juju deploy cs:trusty/ubuntu
[04:15] <davecheney> ERROR charm not found: cs:trusty/ubuntu
[04:15] <davecheney> Y NO TRUSTY CHARM!!!
[04:16] <marcoceppi> because we no promulgate trusty charms yet
[04:17] <davecheney> Y U KEEP CHRM SECRETT
[04:17] <jose> marcoceppi: oh, do you have a link to those trusty tests docs you mentioned?
[04:18] <marcoceppi> davecheney: because charms have no tests!
[04:18] <marcoceppi> jose: which trusty tests docs?
[04:18] <jose> you mentioned having some docs about writing the tests for charms to be on trusty
[04:18] <davecheney> marcoceppi: ubuntu charm is awesome, it is the chuck norris of charms
[04:19] <davecheney> it doesn't need tests
[04:19] <marcoceppi> davecheney: you bring up a good point though, we need to start testing trusty like tomorrow
[04:19] <davecheney> marcoceppi: i need to test it like months ago :)
[04:20] <marcoceppi> davecheney: I can push the ubuntu charm to trusty if you'd like
[04:20] <marcoceppi> it's obviously going to work
[04:23] <marcoceppi> davecheney: cs:trusty/ubuntu exists now, may take a few mins for the store to find it
[04:23] <marcoceppi> davecheney: nope, it found it https://store.juju.ubuntu.com/charm-info?charms=cs:trusty/ubuntu
[04:24] <jose> marcoceppi: juju first downloads the precise image before deploying, right?
[04:24] <marcoceppi> jose: yes, the precise clodu iamge
[04:24] <jose> then it'll take a good while
[04:25] <jose> I better go grab a cup of coffee
[04:29] <davecheney> marcoceppi: w00000000t
[04:29] <davecheney> thanks
[04:30] <davecheney> i can use a local charm
[04:30] <davecheney> but the whole test is that we can talk to thet charm store via a proxy
[04:30] <davecheney> so local charms defeate the purpose
[04:30] <marcoceppi> davecheney: I want to enable you FOR GREATNESSS
[04:30] <davecheney> thank you sir
[04:30] <davecheney> do you have a suitable imgur for this ?
[04:34] <marcoceppi> http://i.imgur.com/1ida17K.jpg
[04:34] <marcoceppi> not relaly
[04:34] <sarnold> awesome though :)
[04:34] <marcoceppi> though I've been abusing this one recently, davecheney, http://i.imgur.com/9EqJvVX.gif
[04:42] <jose> marcoceppi: hey, it says 'instance-state: missing'
[04:43] <marcoceppi> jose: that's progress, what does ~/.juju/local/log/machine-0.log have for contents?
[04:43] <jose> hmm, /me checks
[04:44] <jose> marcoceppi: http://paste.ubuntu.com/7088329/
[04:45] <marcoceppi> jose: it looks like it's still progressing
[04:45] <marcoceppi> give it a few more mins checking juju status occasionally
[04:45] <jose> sure, thanks
[04:46] <marcoceppi> jose: what does sudo lxc-ls --fancy show?
[04:46] <jose> state: running, gives me an ip address
[04:47] <jose> marcoceppi: mind a PM on another topic?
[04:47] <marcoceppi> sure
[04:56] <jose> marcoceppi: I cannot seem to find the error on config-changed... Everything looks sane to me
[04:57] <marcoceppi> jose: let me get you the log
[04:59] <marcoceppi> http://paste.ubuntu.com/7088378/ jose
[05:00] <bodie_> night all
[05:03] <jose> let's see
[05:12] <jose> oh, I'm going to check that
[07:05] <ev> is there any way to stop juju from tearing down the instance when it fails to bootstrap, so I can investigate why?
[07:06] <ev> I'm seeing:
[07:06] <ev> Bootstrapping Juju machine agent
[07:06] <ev> 2014-03-14 06:51:09 ERROR juju.provider.common bootstrap.go:123 bootstrap failed: rc: 1
[08:06] <stub> I don't suppose there is a daily package built of HEAD somewhere?
[08:09] <stub> https://code.launchpad.net/~dave-cheney/+recipe/juju-core-daily no longer seems to exist
[09:14] <JoshStrobl> Hey guys, where is the Charm Bundle lesson?
[09:17] <JoshStrobl> marcoceppi: says you'll be on of the speakers, where's the stream?
[09:18] <JoshStrobl> hmm, maybe my Google Calendar just got messed up or something and is displaying the wrong time to me
[09:20] <JoshStrobl> oh yea, 1400 EST on Friday (just looked at the email). Good job Google, waking me up for no reason :\
[09:21]  * JoshStrobl goes back to bed
[12:20] <rbasak> hazmat: got an issue with python-websocket-client, which python-jujuclient uses.
[12:21] <rbasak> hazmat: I need to shift the dependency to python-websocket, since we have a dupe. This involves effectively bumping the version in Trusty from 0.11.0-0ubuntu1  to 0.12.0-1
[12:21] <rbasak> hazmat: do you see any problems with that?
[12:21] <rbasak> jamespage: ^^
[12:21] <jamespage> rbasak, going to give it a quick test as well
[12:21] <jamespage> I use deployer alot
[12:24] <hazmat> rbasak, should be fine.. i'll double check re changes
[12:24] <hazmat> rbasak, yup that's fine.. i use that version already
[12:25] <hazmat> via pip/virtualenv installs
[12:26] <rbasak> hazmat: thanks!
[13:16] <jcastro> mbruzek, lazyPower, those errors you got with the subordinates and the bundles last night, you got those in the GUI right?
[13:17] <mbruzek> jcastro, I was using the command line.  I did not see any errors, I only saw 3 charms deployed from that bundle.
[13:18] <mbruzek> I am sure there were errors that prevented that from deploying, but I didn't dig into it.
[13:18] <rick_h_> jcastro: the gui was watching the bundle and returned the error to the user
[13:18] <rick_h_> jcastro: but the error came from lower down the stack
[13:19] <jcastro> mbruzek, can you see if you have the bundles you tried  in your history? I'd like to dig today
[13:21] <mbruzek> jcastro, http://pastebin.ubuntu.com/7090108/
[13:21] <mbruzek> I destroyed the environment at the EOD but that is how I ran it.
[13:21] <jcastro> ah got it
[13:21] <jcastro> I mistakingly put in the "complex", but chuck caught that and I removed it
[13:21] <jcastro> pushed a new version, trying it now
[13:22] <mbruzek> Out of that list of charms, I only saw juju-gui, kibana, and haproxy deployed iirc
[13:22] <jcastro> yeah, rails takes like 10 minutes at least
[13:22] <jcastro> it does all this ... rails stuff ...
[13:22] <jcastro> pull the universe from git, etc.
[13:22] <jcastro> I am trying it now
[13:23] <mbruzek> OK
[13:28] <zchander> Hi all... Got another (weird) error. Just reinstalled my MaaS and whenI want to bootstrap my Juju, I get iscsi errors
[13:50]  * zchander seems baffled.... Somehow some ephemerals were installed twice...... :(
[13:51] <lazyPower> jcastro: i've tried it on several installations. the units were never coming online
[13:51] <lazyPower> that error failed the entire bundle deployment. i'm not saying its not my env being the culprit though
[13:51] <jcastro> yeah rick is investigating
[13:51] <jcastro> no I reproduced, and so did mbruzek just now
[13:51] <lazyPower> ah ok
[13:51] <jcastro> but this exact bundle was working a few days ago, so clearly something changed
[13:52] <jcastro> lazyPower, I am worrying about the sample app in the rails charm though
[13:52] <mbruzek> jcastro, that pastebin was from yesterday
[13:52] <jcastro> mbruzek, yeah the exact same thing happened to me
[13:52] <jcastro> just now
[13:52] <mbruzek> Ok
[13:55] <lazyPower> jcastro: ok let me wrap this subordinate I am hacking on and I'll pull that sample rails app and see how it goes
[13:55] <jcastro> I am +1 if you want to replace pavel's app with another hello-world style app
[13:56] <lazyPower> actually
[13:56] <lazyPower> let me deploy pavels app on the rails charm now. it wont take long
[13:56] <rick_h_> jcastro: [E 140314 09:52:59 utils:72] error deploying the bundle                                                                                │·······················
[13:56] <rick_h_> [E 140314 09:52:59 utils:73] error type: <class 'jujuclient.EnvError'>                                                                                │·······················
[13:56] <rick_h_> [E 140314 09:52:59 utils:79] error message: subordinate service must be deployed without units
[13:57] <jcastro> how did it let me create that in the first place?
[13:58] <rick_h_> jcastro: wow, this error was mentioned in our irc back in July
[13:59] <jcastro> well, I prefer known to unknown. :)
[13:59] <rick_h_> http://irclogs.ubuntu.com/2013/07/24/%23juju-gui.txt line 73
[14:00] <jcastro> ok so worse case, remove the subs
[14:00] <jcastro> but then the bundle is kind of less useful
[14:00] <rick_h_> jcastro: pulling num_units and going to try it out again
[14:00] <rick_h_> jcastro: I think just removing the unit specifier will work, but testing
[14:01] <jcastro> ok
[14:01]  * Makyo is back (gone 13:44:06)
[14:03] <jcastro> rick_h_, the django bundle has the same errrors
[14:03] <jcastro> so hopefully that's the badger
[14:03] <rick_h_> jcastro: in looking at the source code here, num_units isn't valid param for subordinates. Did you export this? I thought we didn't export that value any more
[14:03] <jcastro> I exported it
[14:03] <jcastro> I've done no manual mangling other than renaming the envExport
[14:04] <rick_h_> jcastro: will file a bug on that then. We shouldn't export that setting
[14:04] <jcastro> ok so I should remove that from the bundle and try again?
[14:04] <jcastro> rick_h_, remove all of the num_units right?
[14:05] <rick_h_> hmm, same error
[14:05] <rick_h_> jcastro: yea it's what I did to try out but failed again
[14:05]  * jcastro stands by
[14:07] <rick_h_> jcastro: which are sub's in here?
[14:08] <jcastro> logstash agent
[14:08] <rick_h_> nrpe?
[14:08] <jcastro> maybe nrpe?
[14:08] <jcastro> I don't remember, I made the bundle like 3 weeks ago, heh
[14:08] <jcastro> iirc I thought subs would be mentioned in the file
[14:09] <lazyPower> rick_h_: confirmed nrpe and logstash-agent are the subs
[14:10] <rick_h_> lazyPower: k, trying another take
[14:11] <rick_h_> jcastro: ok, change the num_units to 0
[14:11] <rick_h_> on the subs
[14:12] <rick_h_> jcastro: don't ask me why, but it's what the code says and it's deployed the rest of the services. So run with me here :)
[14:12] <rick_h_> lazyPower: ^
[14:12] <rick_h_> for the django one
[14:12] <rick_h_> as well I'd imagine
[14:12] <jcastro> neither nrpe or logstash-agent have num_units mentioned
[14:13] <jcastro> do you think it's assuming one? so explicitly add it and declare 0?
[14:13] <lazyPower> rick_h_: http://i.imgur.com/00Ugaft.gif
[14:13] <rick_h_> jcastro: yes, it seems to assume 1 and then error. I set it to 0 and it's working
[14:14] <jcastro> man, that's an awesome bug
[14:14] <rick_h_> jcastro: pretty much
[14:16] <rick_h_> jcastro: k, all done. rails failed on install hook error but the rest went out
[14:16] <rick_h_> the sample app one that is
[14:17] <marcoceppi> jcastro: I take issue with the way the rails bundle is structured
[14:17] <jcastro> marcoceppi, ok
[14:17] <marcoceppi> Since it's a "framework" charm it's still to just deploy it
[14:17] <jcastro> fire away
[14:18] <marcoceppi> We should instead model some rails software in the bundle instead
[14:18] <marcoceppi> like rails/<rails-app-thin>
[14:18] <marcoceppi> since bundles should model workloads
[14:18] <marcoceppi> find popular rails apps and build bundles for them in the rails name space
[14:18] <lazyPower> marcoceppi: I suggested stringer as a possible replacement.
[14:18] <lazyPower> another one would be spree, the ecommerce solution.
[14:19] <marcoceppi> another issue with the charm in general, but it's not your fault jcastro, is a lot of times it needs post-deployment commands to work properly
[14:19] <jcastro> yes, I had to mention that
[14:19] <marcoceppi> (db:migrate, asset"precompiile, etc)
[14:19] <marcoceppi> jcastro: http://stackoverflow.com/a/487407/196832
[14:19] <jcastro> basically, django and rails need things like, a config.yaml for where the code lives, etc.
[14:20] <lazyPower> marcoceppi: since we cleared the security groups lastnight I haven't been able to reach anything i've deployed on HPCloud - is there a stray setting aside from the .jenv i need to wipe?
[14:21] <lazyPower> wait, i can reach it via ssh, but not port80 post being exposed
[14:21]  * lazyPower wat's
[14:21] <marcoceppi> lazyPower: did you have anything deployed before the wipe?
[14:21] <lazyPower> i did :(
[14:21] <marcoceppi> yeah, they're inaccessible
[14:21] <lazyPower> i had a bootstrap node chillin in there that I manually wiped from the console.
[14:22] <marcoceppi> best to destroy environment and move on
[14:22] <lazyPower> i just rebootstrapped
[14:22]  * lazyPower wipes and tries again
[14:30] <jcastro> marcoceppi, ok how about example-single and example-scalable?
[14:30] <jcastro> to make it explicit that it's a hello world for you to customize?
[14:30] <marcoceppi> jcastro: such compromise
[14:30] <marcoceppi> jcastro: much synergy
[14:31] <jcastro> rick_h_, blamo, worked first time
[14:31] <jcastro> ok going to do what marco wants, push, and then we'll see about the example app
[14:31] <jcastro> going to fix/push django too
[14:32] <marcoceppi> so, probably needs to be on deployer than
[14:32] <rick_h_> jcastro: woot thanks for the help in debugging. I've got a card for us to find the right place to file the bug.
[14:32] <marcoceppi> a bug*
[14:58] <rbasak> hazmat: about python-jujuclient again. test_jujuclient.py is in bzr, but not in the PyPI distribution, so I can't easily run the test suite as part of a package build (MIR requirement).
[14:58] <rbasak> hazmat: I just dealt with exactly this problem in websocket-client by plucking out the test suite in a packaging patch.
[14:59] <rbasak> hazmat: please can you add it to setup.py?
[15:01] <hazmat> rbasak, sure
[15:01] <hazmat> rbasak, i hadn't realized this was going into main
[15:01] <hazmat> rbasak, i've got meetings for the next 2hrs but will come back to it today
[15:02] <rbasak> hazmat: np. Unless you do a PyPI release and I update packaging I'll have to do a distro patch anyway.
[15:02] <rbasak> hazmat: it's going into main because juju-quickstart needs it.
[15:03] <rbasak> hazmat: "Seriously Alpha. Works now, but API *will* change." alarms me a little for main inclusion.
[15:04]  * rbasak takes a break to unwind his stack
[15:06] <hazmat> rbasak, yeah.. i should take that out, it was commentary from the first release against the api, but in truth it has been pretty stable to date
[15:07] <rbasak> hazmat: thanks. I will quote that for the MIR :)
[15:47] <onrea> fainally, I could not run Discourse.org by juju :(
[15:48] <onrea> My problem is repored here: http://discourse.ubuntu.com/t/how-to-install-juju-manually-cloudimg-tar-gz-where-should-it-be-extracted/1548
[15:49] <onrea> if you can help, please help
[15:56] <onrea> lazyPower: ^
[15:58] <lazyPower> onrea: ack, hang on i'm going to tap one of the more knowledgeable people
[16:00] <marcoceppi> onrea: put them in /var/cache/lxc/cloud-precise but don't extract them
[16:00] <onrea> :)
[16:00] <onrea> both of them?
[16:00] <marcoceppi> onrea: yes
[16:01] <onrea> w8
[16:03] <onrea> marcoceppi: PLease check the instruction for any missing/wrong step:
[16:03] <onrea> 1. sudo juju destroy-environment -y local
[16:03] <onrea> 2. juju init && juju switch local
[16:03] <onrea> 3. sudo chown -R emzi.emzi ~/.juju ~/.ssh
[16:03] <onrea> 4. juju bootstrap
[16:04] <lazyPower> onrea:  once you've dstroyed you don't need to re-init
[16:04] <onrea> 5. juju deploy --repository=$HOME/charms local:discourse
[16:04] <onrea> 6. juju deploy postgresql
[16:04] <onrea> 7. juju add-relation discourse postgresql:db-admin
[16:04] <onrea> 8. juju expose discourse
[16:04] <onrea> 9. juju status
[16:04] <onrea> 10. watch juju status
[16:04] <onrea> lazyPower: ok
[16:05] <lazyPower> onrea: otherwise that set of instructions loks fine, i don't see anything crazy
[16:06] <onrea> Ok, thanks @lazyPower, marcoceppi. I'm going to rock discourse with juju...
[16:33] <jcastro> ERROR cannot use 37017 as state port, already in use
[16:33] <jcastro> anyone know how to fix this one with the local provider?
[16:34] <jcastro> I've blown away local.jenv and the environment/local directory
[16:40] <marcoceppi> jcastro: sudo initctl list | grep juju
[16:42] <jcastro> ok I see stuff
[16:42] <jcastro> do I stop/restart it?
[16:43] <rick_h_> jcastro: yea, I just ps aux | grep mongo and kill the mongodb instance running
[16:43] <marcoceppi> jcastro: sudo stop each of those
[16:44] <marcoceppi> then rm -f /etc/init/juju-*
[17:37] <jcastro> ==> unit-jenkins-slave-0.log <==
[17:37] <jcastro> 2014-03-14 17:37:43 ERROR juju runner.go:220 worker: exited "upgrader": cannot read tools metadata in tools directory: open /home/jorge/.juju/local/tools/<IP_ADDRESS>-prec
[17:37] <jcastro> ise-amd64/downloaded-tools.txt: no such file or directory
[17:38] <jcastro> I've not run into this before
[17:39] <lazyPower> jcastro: this is something that happened during the 1.17.4 update - if you ln -s the saucy tools to precie it goes awy
[17:39] <lazyPower> and its only log spam - it doesn't appear to have any effect over deployments in my testing.
[17:40] <lazyPower> s/precie/precise
[17:40] <jcastro> I don't have saucy or precise tools
[17:40] <lazyPower> are you running trusty?
[17:40] <jcastro> yeah
[17:40] <lazyPower> probably trusty-tools then
[17:40] <lazyPower> same principal
[17:40] <lazyPower> but ymmv - i dont know if there was a specific difference between the series.
[17:41] <jcastro> ah
[17:41] <jcastro> I don't seem to have /releases/juju-<IP_ADDRESS>-trusty-amd64.tgz
[17:41] <jcastro> can I sync-tools post-bootstrap?
[17:41] <lazyPower> good question
[17:42]  * jcastro tries it
[17:42] <lazyPower> i think so
[17:42] <lazyPower> juju sync-tools is referenced in this answer
[17:42] <lazyPower> http://askubuntu.com/questions/285395/how-can-i-copy-juju-tools-for-use-in-my-deployment
[17:43] <jcastro> it didn't work, but the service is up
[17:43] <jcastro> so Good Enough
[17:44]  * lazyPower nods
[17:44] <lazyPower> the log spam is annoying, i'll file a bug
[17:45] <jcastro> well, the tools are also missing
[17:45] <jcastro> that might be a problem, heh
[17:45] <lazyPower> yikes!
[17:45] <lazyPower> sinzui: anything going on with streams/tools that you are aware of?
[17:46] <sinzui> Nothing yet.
[17:46] <lazyPower> brb
[17:47] <sinzui> lazyPower, It is stable right now. When will ask for an update to get 1.17.5 when I see the arm64 and ppc packages in ports
[17:53] <lazyPower> sinzui: ack, thank you for looking into this for us
[17:58] <jcastro> Juju Charm School on Bundles in 2 minutes!
[17:58] <jcastro> https://plus.google.com/hangouts/_/hoaevent/AP36tYdbEgmEEjOzBoN2_eYNDyWicF98hHYXAdD2H92SaNCpwqY1DA?authuser=0&hl=en
[17:58] <jcastro> there's the URL
[17:58] <jcastro> http://youtu.be/eYpnQI6GZTA if you just want to follow along
[18:01] <JoshStrobl> Will the Youtube stream automatically start playing the video once it's being broadcasted?
[18:01] <marcoceppi> JoshStrobl: yes, should start in a few mins
[18:01] <JoshStrobl> cool
[18:01] <marcoceppi> JoshStrobl: rather, it should be running now
[18:01] <marcoceppi> may need to refresh
[18:02] <JoshStrobl> yep!
[18:02] <JoshStrobl> refreshed and it's buffering
[18:02] <JoshStrobl> well, it's loading as in waiting...or something like that. no way it's buffering on my connection
[18:03] <lazyPower> JoshStrobl: its live for me - still having issues?
[18:04] <JoshStrobl> not any more. just ended up loading firefox and it was fine
[18:04] <JoshStrobl> good job Chrome, good job...
[18:04]  * lazyPower golf claps for chrome
[18:05] <marcoceppi> Feel free to ask questions anyone watching, and I'll relay them in to the video!
[18:11] <JoshStrobl> aanndd this is why I use nano in the terminal :P
[18:16] <ppetraki> any questions so far?
[18:17] <bac> jcastro: the ingest runs every 15 minutes, so worst case is you just miss and it takes two cycles, 30 minutes
[18:21] <JoshStrobl> No questions from me :(
[18:21] <JoshStrobl> * :)
[18:23] <lazyPower> jcastro: you should be able to drag directly from the rails charm to that mongos instance in the middle.
[18:24] <lazyPower> jcastro: crazy? that was every day in a prior life :)
[19:07] <JoshStrobl> hey lazyPower, I changed my charm from Incomplete to Fix Committed again barring a response from you (regarding my response to you): https://bugs.launchpad.net/bugs/1278369 . Waiting a while and noticed there wasn't any reply on it when it hadn't been changed, so I went ahead and changed it.
[19:07] <_mup_> Bug #1278369: Charm Needed: metis <new-charm> <Juju Charms Collection:Fix Committed by truthfromlies> <https://launchpad.net/bugs/1278369>
[19:08] <lazyPower> JoshStrobl: thanks! i reached out and didn't receive an email response - so without it being in teh queue and no 1:1 from you it was pending re-entry into the queue
[19:08] <lazyPower> i should be able to get you the +1 today before I EOD
[19:08] <JoshStrobl> lazyPower: Ah, thought that since ~charmers were subscribed that maybe it'd notify others, guess not.
[19:09] <lazyPower> yeah - with me not being a charmer yet (emailing the list today to petiton for membership) - i don't get those notifications yet.
[19:10] <JoshStrobl> lazyPower: I changed to Fix Committed since it was more relevant to my actual post (I had changed to Fix Committed prior to you setting it as Incomplete since like 99% of everything marcoceppi talked about was resolved). Not necessarily looking for the +1 (although that'd be nice), more like "hey, the stuff you said wasn't resolved actually was, here is a long post about it".
[19:14] <JoshStrobl> If you have any questions and feel it'd be more appropriate to discuss on IRC rather than mailing list, I'll obviously be around...probably for 5 or so more hours.
[19:19] <lazyPower> JoshStrobl: ack. I'll ping you shortly
[19:19] <lazyPower> wrapping up some expedited requests now
[19:28] <jose> lazyPower: hey, if you're around and have a minute, looks like I fixed the mailman charm
[19:28] <lazyPower> jose: awesome :) did you move the status of your ticket to fix committed?
[19:29] <jose> lazyPower: well, to new, but moved it
[19:29] <lazyPower> ack. as long as its in the revq i'll get to it before my shift ends for teh week
[19:36] <lazyPower> JoshStrobl: ok moving on to metis - incoming review
[19:37] <JoshStrobl> lazyPower: Thanks bud.
[19:45] <lazyPower> JoshStrobl: without cryptograhic verification of file signatures I cannot pass the charm, its a hard stopper. I respect your concern of continuous delivery though
[19:45] <JoshStrobl> lazyPower: Any suggests?
[19:45] <JoshStrobl> *suggestions
[19:45] <lazyPower> My thought would be to use git itself as the delivery mechanism, since git validates the file signatures cryptographically
[19:46] <lazyPower> you can use tags in the same vein as you would be zip packages
[19:46] <lazyPower> then you just deliver from your github repository using the tag, and make tag the configuration option for deployment
[19:46] <lazyPower> or hash, or whatever. This satisfies a default stable release and allows for upstream deployment as well so you're not updating your charm over and over to get the new releases in
[19:48] <JoshStrobl> Gonna be honest, didn't even think about using git. Feel free to mark as Incomplete barring fix, I'll implement using git as the delivery mechanism when I get the chance and will change it to Fix Committed when it's done.
[19:48] <JoshStrobl> *git for delivery
[19:48] <lazyPower> JoshStrobl: if you want any help/pointers ping me and I'll hop on a hangout with you
[19:48] <JoshStrobl> Cool, thanks!
[19:48] <lazyPower> and thank you for being patient during the review process, i know this has quite a bit of back and forth. I want to see this land in the charm store soon after seeing how much effort you've put into it
[19:49] <JoshStrobl> lazyPower: Thanks for your kind words and the tip on using git (makes sense since the code is on GitHub anyways) =)
[19:57]  * lazyPower hat tips
[19:57] <lazyPower> jose: incoming mailman review
[19:57] <jose> lazyPower: thanks!
[20:49] <lazyPower> jose: correct me if i'm wrong, but i'm seeing the same failure
[20:49] <lazyPower> was this corrected on the postfix charm?
[20:49] <jose> lazyPower: hmm? let me double check
[20:49] <lazyPower> as that may be why i'm not seeing the fix show up
[20:49] <jose> no, it was corrected on the mailman charm
[20:50] <jose> let me double check just in case
[20:50] <lazyPower> ack
[20:50] <jose> hmm, no, it was corrected on the 7th revision
[20:50] <jose> which is on LP atm
[20:51] <jose> I did a successful deploy with it on my local env yesterday
[20:51] <lazyPower> I'm sitting on revision 5
[20:51] <lazyPower> and it just updated
[20:51] <lazyPower> wat...
[20:51] <lazyPower> i'm slippin
[20:51] <lazyPower> ok let me upgrade the charm and start over - ty for confirming
[20:52] <jose> :P np
[20:54] <lazyPower> good news! it passed the config-changed hook blocker
[20:54] <lazyPower> moving on
[21:18] <lazyPower> ok last call for anyone with last minute charm submissions before i EOD
[21:18] <lazyPower> you've got 15 minutes
[21:36]  * lazyPower EOD's
[21:37] <lazyPower> jose: ping me when you've got those changes and i'll re-review for ya later tonight and get your +1 on record
[21:37] <jose> awesome, thanks!
[21:37] <lazyPower> JoshStrobl: not sure if you're still hacking away, but same goes for you.
[21:45] <dpb1> marcoceppi: hi -- amulet is supposed to intercept calls to deploy the "current" charm, right?  We are seeing that isn't happening as we expect.  Known issue?
[21:46] <marcoceppi> dpb1: how are you executing the test with charm test or directly?
[21:46] <marcoceppi> if directly you'll need to see this Ask Ubuntu question
[21:47] <dpb1> hmmm.
[21:47] <dpb1> charm test?
[21:47] <dpb1> we are using juju test
[21:47] <marcoceppi> dpb1: that's one in the same
[21:48] <dpb1> reading in a deployer config file with 'branch: lp:~landscape-charm/trunk'
[21:48] <marcoceppi> juju test == charm test; are you launching juju test from the charm_dir?
[21:48] <dpb1> yes
[21:48] <marcoceppi> dpb1: OH
[21:48] <marcoceppi> that's why
[21:48] <dpb1> :(
[21:48] <marcoceppi> it only intercepts on d.add()
[21:48] <marcoceppi> dpb1: file a bug and I'll see what I can do
[21:49] <dpb1> OK
[21:50] <dpb1> marcoceppi: there are other problems with the config-based deployment that I haven't filed yet.  But this one is more tricky for me to work around.
[21:51] <ahasenack> marcoceppi: what do you whink about this other idea,
[21:51] <ahasenack> marcoceppi: when creating a deployment, like
[21:51] <ahasenack>     d = amulet.Deployment(sentries=False)
[21:51] <ahasenack> marcoceppi: pass it an existing directory where I have already checked out all the branches I want deployer to use
[21:52] <ahasenack> it's like pre-creating precise/<charms>, and then calling deployer
[21:52] <ahasenack> it will see the charms are already there and not update them, nor check them out again
[21:53] <ahasenack> so, I would call it like
[21:54] <ahasenack> d = amulet.Deployment(sentries=False, charm_directory="/some/path")
[21:54] <ahasenack> it would use charm_directory instead of a temporary directory to check out all the charms
[22:54] <fishy_> what username and password can I do to get into a new local charm I just started?
[22:54] <fishy_> assume I would do a sudo lxc-console --name <foo>
[23:06] <jose> lazyPower: should be ready for review, but needs the 'password' option set for the install hook to run successfully
[23:06] <lazyPower> jose: ack - do a sniff for the presence of the password config option, if its not present, dont run the hook
[23:06] <lazyPower> that breaks idempotency
[23:07] <jose> huh?
[23:07] <jose> oh
[23:07] <jose> then the charm would not be useful at all, because the service wouldn't even install
[23:07] <lazyPower> $HTPASSWDPW=`config-get password`    if [ -z $HTPASSWDPW ]; # do stuff  fi
[23:07] <lazyPower> im' talking about securing the mailman config interface, dont run the htpasswd generation stuff if options aren't populated
[23:07] <jose> hmm, good idea, not have the htaccess if password is null
[23:07] <jose> yep
[23:08] <lazyPower> :)
[23:13] <jose> lazyPower: aaaaand, pushed!
[23:15] <lazyPower> jose: woo! updating and reviewing now
[23:15] <lazyPower> http://www.youtube.com/watch?v=21OwTUEiGGM#t=231
[23:15] <lazyPower> watch that while you wait
[23:15] <jose> :P
[23:25] <lazyPower> jose: really close - move that logic to the config-changed hook, otherwise its immutable and only runs on install
[23:25] <jose> lazyPower: hmm, in what part?
[23:27] <jose> like, adding support to change the password?
[23:27] <lazyPower> jose: the heredoc configuration where you're generating the htpasswd and setting the apache values for the htpasswd
[23:27] <lazyPower> right :)
[23:28] <lazyPower> immutable configuration options will wind up tanking a review just as fast as a broken hook - because its not readily apparent to the user that its only configurable during install, and thats a pretty easy copy/paste job to move it.
[23:32] <jose> lazyPower: all set now
[23:35] <lazyPower> deploying
[23:37] <jose> lazyPower: thanks a lot for your help, owe you a couple beers once we meet at a conference
[23:37] <lazyPower> jose: nbd :) I enjoy the candor though
[23:47] <lazyPower> jose:         agent-state-info: 'hook failed: "install"'
[23:47] <jose> lazyPower: does it give you any clues on the log?
[23:47] <jose> I'll try and deploy, but will take a while
[23:47] <lazyPower> ln: failed to create symbolic link `/etc/apache2/sites-enabled/mailman': File exists
[23:48] <jose> hmm? /me double checks
[23:49] <jose> lazyPower: weird, I don't see that on my logs
[23:51] <lazyPower> thats on a fresh local provider environment
[23:51] <lazyPower> the install hook is only run once though - so if you're updating a unit, you wont see that
[23:51] <jose> I just destroyed my local environment and bootstrapped again
[23:51] <jose> it's deploying


[00:16] <mwhudson> https://launchpadlibrarian.net/174134069/buildlog_ubuntu-utopic-arm64.scrub_2.5.2-2_FAILEDTOBUILD.txt.gz <- this just means "pls update config.guess" right?
[00:17] <infinity> mwhudson: Yep.
[00:19] <infinity> mwhudson: Fixing.
[00:19] <mwhudson> infinity: how can i make that happen?
[00:19] <mwhudson> oh cool
[00:19] <mwhudson> (not that i'm completely sure this is relevant to me today but it's the end of this branch of the rabbit hole)
[00:26] <infinity> mwhudson: Fixed in utopic-proposed.
[00:26] <infinity> Well, soonish.
[00:26] <mwhudson> infinity: will something that's depwaiting on that automagically try again ?
[00:26] <mwhudson> eventually
[00:26] <infinity> mwhudson: Yeah.
[00:26] <infinity> mwhudson: Though if you identify that something, we can certainly force the issue earlier.
[00:26] <mwhudson> of course the builds that didn't depwait out failed so eh
[00:27] <mwhudson> infinity: https://launchpad.net/ubuntu/+source/libguestfs/1:1.26.1-1ubuntu1
[00:27] <mwhudson> cp: cannot open '/boot/vmlinuz-3.13.0-24-generic' for reading: Permission denied
[00:28] <mwhudson> this seems like the sort of thing that is well known about guestfs (even i know about it!)
[00:28] <mwhudson> apw: i presume you're asleep like a sensible person?
[00:29] <infinity> mwhudson: That's a fundamentally broken thing with that package...
[00:29] <mwhudson> yeah
[00:29] <mwhudson> i recall upstream was not very sympathetic to ubuntu's position...
[00:29] <infinity> mwhudson: Andy and I have spent some time talking about it, but if you have good ideas to make it less stupid before he fixes it, go nuts. :P
[00:29] <mwhudson> i have no ideas, but running tests that rely on that being readable is not going to work...
[00:30] <infinity> It's not tests.
[00:30] <infinity> It's trying to copy the *&!% kernel into its resulting binary.  I think.
[00:30] <mwhudson> oh
[00:30] <mwhudson> pff
[00:30] <infinity> Or maybe I'm tihnking of a different broken package.
[00:30] <infinity> Anyhow, it's all bad.
[00:31] <mwhudson> this one is a test i think
[00:32] <infinity> Well, that's less bad.
[00:32] <infinity> Err, are you sure?
[00:32] <infinity> supermin is trying to build a filesystem.
[00:32] <infinity> And copy the kernel over.
[00:33] <mwhudson> it's from running make -C /build/buildd/libguestfs-1.26.1/debian/build-python3.4 quickcheck
[00:33] <mwhudson> i think?
[00:33] <mwhudson> i might be mis-reading
[00:33] <infinity> Oh, it might be a check from the POV of libguestfs.  But the bug is in supermin.
[00:34] <infinity> You could not run that test that uses supermin, but I don't think that really gets you anywhere interesting, if it's meant to be used in conjunction.
[00:34] <mwhudson> all i was trying to do was install python-guestfs because the openstack install guide said do :-)
[00:34] <mwhudson> *to
[00:51] <psusi> infinity, poke ;)
[00:52] <infinity> psusi: Ow.
[00:52]  * psusi hands infinity the rubber chicken
[00:53] <psusi> how's that thar util-linux going?
[00:53]  * infinity slaps psusi with it, in anticipation of his next question.
[00:53] <infinity> Guess I should have typed that a bit faster.
[00:54] <infinity> psusi: It's coming along.  I've enlisted others.
[00:54] <psusi> lol... ok... any estimates?  half way done or what?
[00:55] <infinity> No estimates.  It'll happen and it won't miss either upcoming release.
[00:55] <infinity> Estimates just seem to be an invitation for people to be extra annoying.  But it's being worked on, not forgotten.
[00:56] <psusi> ok... it's pretty slow going isn't it?
[00:57] <infinity> I haven't done the "take work time to JFDI" bit yet.  That might be coming soon.
[00:57] <psusi> *lots* of patches in there
[01:00] <psusi> did I already ask you this?  what do you think of the /etc/mtab -> /proc/mounts migration?  something we want to do for utopic?
[01:00] <infinity> psusi: I believe slangasek had strong feelings about why that can't happen.
[01:00] <infinity> psusi: WRT network filesystems.
[01:01] <psusi> hasn't debian sorted that all out by now?  they made the migration some time ago now
[01:01] <infinity> Erm, they did?
[01:03] <psusi> afaics from upstream, you just need to link the mount helpers against libmount and it takes care of stashing the extra parameters in utab instead
[01:04] <infinity> Well, we'll cross that bridge when we get to it.  But the "they did?" comment was me looking at a sid chroot.
[01:04] <infinity> Where, if Debian has "migrated", I would expect to see an /etc/mtab -> /proc/mounts symlink, which isn't there.
[01:04] <infinity> So, they didn't migrate very hard, if they did. :P
[01:05] <psusi> hrm... I think the way they did the migration was kind of goofy... its' there in a fresh vm install
[01:13] <infinity> psusi: Right, so it happens on boot (every boot!) via /lib/init/mount-functions.sh, called by /etc/init.d/checkroot.sh
[01:14] <psusi> yea.. it should be done in postinst instead
[03:52] <slangasek> infinity: heh; yes, Debian migrated /etc/mtab to /proc/mounts, without cleaning up the migration bugs.  There's still an open bug report from me against util-linux about this, Debian bug #702935.
[04:01] <infinity> slangasek: Ta.
[04:02] <slangasek> infinity: so recasting psusi's question as "can we do this migration in Ubuntu that there's currently an open RC bug about in Debian on a package I'm keen to adopt?"... ;)
[04:03] <infinity> slangasek: Right, I think the way forward is to clean this up in Debian while I'm cleaning up util-linux in general, and then make it work in Ubuntu.
[04:03] <slangasek> sure
[05:16] <pitti> Good morning
[05:18] <Unit193> Howdy.
[05:25] <Unit193> pitti: I suppose you saw https://lists.debian.org/debian-devel/2014/05/msg00469.html and it's pointless for me to link?
[05:29] <pitti> Unit193: no, I'm not on d-devel; shim will *not* work with > 204 at the moment
[05:29] <pitti> that requires quite some work with cgmanager and systemd-shim first
[05:29] <Unit193> Yes, he stated that in a follow-up. :)
[07:03] <dholbach> good morning
[07:32] <tsdgeos> tkamppeter: is there any chance we can get http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=3c4cfba8 into our gs 9.14 packages?
[08:13] <Mirv> pitti: hey, ubuntuone-credentials autopkgtest is failing for everything and doing a bit of blocking, is there a possibility you could glance at that?
[08:14] <pitti> Mirv: looks like a missing test dependency at first, yes
[08:14] <pitti> Mirv: I'll have a look
[08:16] <Mirv> thank you!
[08:16] <tkamppeter> tsdgeos, I can do, no problem.
[08:16] <tsdgeos> tkamppeter: great :)
[08:18] <pitti> Mirv: meh, ubuntuone-credentials' autopkgtest is rather useless
[08:20] <pitti> and I can't push to the branch either
[08:20] <pitti> *grumble*
[08:22] <pitti> Mirv: yep, the test is right -- the package really is FTBFS (checked in sbuild)
[08:25] <pitti> Mirv: filed bug 1318947 to track this; checking with adding pkg-config as build dep
[08:27] <Mirv> pitti: ok, good. yeah, I actually suspected that since the phone stuff tends to develop so fast the rarer updated packages start FTBFS:ing at times.
[08:27] <Mirv> when I was preparing Qt 5.2, I ran into many of such that failed to build even against the archive version
[08:27] <pitti> so adding pkg-config build dep helps; I'll let this build finish and then propose a merge
[08:28] <pitti> debian/tests/control is also rather messy, cleaning this up along the way
[08:33] <pitti> Mirv: https://code.launchpad.net/~pitti/ubuntuone-credentials/fix-ftbfs/+merge/219308
[08:51] <Mirv> pitti: thanks, I tested it now.
[08:52] <pitti> Mirv: I tested in sbuild and adt-virt-qemu
[08:52] <pitti> Mirv: this should also get a ps-jenkins bot approval, right?
[09:00] <Mirv> pitti: I think it should, still, even if the automerger would be disabled for the component because the CI Train process is used instead.
[09:01] <Mirv> dbarth is the lander for ubuntuone-credentials
[09:01] <Mirv> dbarth: https://code.launchpad.net/~pitti/ubuntuone-credentials/fix-ftbfs/+merge/219308 would need to go in
[09:02] <pitti> oh the days when we could just upload these trivial fixes..
[09:02] <pitti> :)
[09:03] <Laney> I still would, and then propose the merge back ;)
[09:03] <pitti> well, it would be nice if people who can upload the package could also commit to the branch
[09:08] <caribou> Laney: remember bug 1296755
[09:08] <caribou> Laney: two tasks are for the -backports pocket (one of which is Quantal)
[09:09] <Laney> caribou: kind of!
[09:10] <caribou> Laney: I uploaded debdiffs for all tasks, though I think that the Quantal one should be dropped; it is EOL in 3 days
[09:11] <Laney> I suppose we can let that slide, yeah
[09:12] <caribou> Laney: well the debdiff is there anyway; I'll resubmit the sponsors & see what the sponsor decides
[09:12] <Laney> backports aren't handled by the sponsors
[09:12] <caribou> Laney: well as I understood, it needs to get to saucy first
[09:13] <Laney> You don't actually need a debdiff for those, assuming the package is identical between saucy and -backports
[09:13] <caribou> Laney: who does worry about -backports ?
[09:13] <Laney> the backporters team
[09:13] <caribou> Laney: ah, ok
[09:13] <Laney> So it'll get into saucy-proposed, then you say "yes I built/installed/ran this on precise and it works" and a copy gets uploaded to precise-backports
[09:14] <Laney> No need for a debdiff unless you need changes over saucy
[09:14] <caribou> Laney: ok, thanks for the details
[09:15] <Laney> np!
[10:08] <dbarth> Mirv: ok, i may add it to my silo; almost done with regression testing
[10:11] <Mirv> dbarth: no need, already taken care of! we needed the packaging fix to unbloc other landings.
[10:32] <shadeslayer> bdmurray: ping
[10:34] <shadeslayer> bdmurray: regarding those crashes in kde-telepathy-contactlist, upstream has pushed a fix here http://quickgit.kde.org/?p=ktp-contact-list.git&a=commitdiff&h=d254bb9779ddf186de33e9482c8668d223339bb5&hp=221d08672a932a2b1cbca3e8eaf46c5465f6d63f , do you reckon I should SRU that or just wait for their next point release which I intend to get SRU'd
[10:34] <shadeslayer> the way that they're triggered is if you have a broken dbus service file for mission-control
[10:40] <ajnas> hello
[10:41] <ajnas> anybody out there?
[10:47] <Ajnas_> helo
[10:48] <tkamppeter> tsdgeos_, ghostscript 9.14~dfsg-0ubuntu2 with the LCMS patch released.
[10:48] <tsdgeos_> :)
[11:11] <shadeslayer> cjwatson: ping
[11:14] <shadeslayer> cjwatson: could you shed more light on your cdimage stuff + PPA association? Does that mean one could provide ISO's which have certain PPA's enabled? Because Kubuntu was thinking of doing that for 14.10 ( have 2 ISO's , one with regular KDE 4 and one with Plasma 5 + KDE Frameworks 5 )
[11:14] <shadeslayer> the latter being provided by a PPA
[11:16] <cjwatson> shadeslayer: I'm not making any promises about how much we can open it up for wider use, because there are resource limits
[11:16] <shadeslayer> cjwatson: right
[11:17] <cjwatson> shadeslayer: And, while the livefs parts of your example would be technically handleable by what I'm doing, there are other things involved in building ISO images with PPAs (i.e. the stuff that goes into the pool) that aren't currently on my list to handle
[11:20] <ogra_> you could just resort to build kubuntu-phone instead ;)
[11:25] <cjwatson> shadeslayer: so, um, the short answer is "maybe" - but I don't think I can make any promises and it may need somebody who cares about this to roll up their sleeves and get involved with the infrastructure
[11:26] <cjwatson> also expanding this by very much is likely to end up blocked on prodstack4 (an IS project) due to librarian disk space limitations
[11:44] <cjwatson> pitti: ubuntu-purchase-service looks like another one of the same species as ubuntuone-credentials?
[11:45] <pitti> cjwatson: right; I'll do a similar MP
[12:23] <mapreri> zequence: I sent you an email some days (7?) ago about xscreensaver. do you mind reply or tell me here your opinion about? otherwise I'll go ahead and drop the ubuntu delta
[12:24] <shadeslayer> cjwatson: ack
[12:29] <mapreri> pitti: anyhow, looking at the changelog seems like the original different split was needed to gain 5 MB on the CD iso (dapper age), so not really useful now :) (just, fyi)
[12:45] <pitti> mapreri: right, because we don't install it at all any more
[12:48] <dobey> Mirv: how about giving the people who actually maintain a project a chance to review an MP before approving it and landing it via CI train?
[12:48] <pitti> cjwatson: https://code.launchpad.net/~pitti/ubuntu-purchase-service/fix-ftbfs/+merge/219361
[12:48] <pitti> Mirv: ^ FYI
[12:48] <dobey> gah
[12:49] <dobey> pitti: why are you removing allow-stderr?
[12:49] <Mirv> dobey: it was a packaging only fix that was needed to unblock other packages, and it could be reverted if wanted then later on
[12:49] <pitti> dobey: as long as these tests don't do anything, they don't need all this noise?
[12:49] <dobey> pitti: the tests do do things
[12:49] <Mirv> dobey: but that ^ ubuntu-purchase-service now blocks 3 packages as well, so it'd be nice to get landed too
[12:49] <pitti> the test is literally just a "set -ex"
[12:49] <pitti> dobey: no, it's a totally empty script except for a "set -ex"
[12:50] <dobey> pitti: the tests are run by the build, which can dump stuff to stderr
[12:50] <dobey> pitti: there's no point in running "make check" and then immediately running "make check" again in the build tree
[12:50] <pitti> dobey: yes, but the build can do that as much as it wants; the build is *not* a test
[12:50] <pitti> (in autopkgtest terms)
[12:50] <pitti> dobey: yes, I agree
[12:50] <pitti> dobey: the point is, an autopkgtest should check the *installed* package, not the build tree
[12:50] <pitti> so you don't need to run make check in an autopkgtest in the first place
[12:51] <dobey> pitti: uh, but it was causing failures before when the build was happening in the autopkgtest, and stderr had things
[12:51] <pitti> something like "make check-installed", or just a small smoketest calling the binaries, etc.
[12:51] <pitti> dobey: well, perhaps you had something in debian/tests/run-tests (which, contrary to its name, doesn't do anything)?
[12:52] <pitti> with set -x being active, any command there would cause stderr
[12:52] <dobey> i don't think so
[12:52] <dobey> but whatever, if autopkgtests start failing, this is probably why :)
[12:52] <pitti> so it's basically the same asa bug 1316416
[12:52] <pitti> dobey: no, it's not; I tested it locally (also with ubuntuone-credentials)
[12:52] <pitti> and if they fail because of stderr, that'd be an autopkgtest bug
[12:52] <dobey> ok
[12:52] <pitti> dobey: but right now they fail because the pacakge is FTBFS
[12:53] <pitti> (new qt stack, some build dep dropping pkg-config dependency; I didn't check and it doesn't matter much)
[12:53] <dobey> an empty run-tests is the only way i've found to make autopkgtests work
[12:55] <pitti> dobey: well, the way to make an autopkgtest work would be to have a test that checks the installed package :)
[12:55] <pitti> we already run the tests against the build tree during package build, so that's not that useful to repeat
[12:55] <dobey> yes, but uploading a new build-dependency doesn't force a rebuild of everything that depends on it
[12:55] <pitti> aside perhaps from issues like these when the pacakge becomes FTBFS due to changes in the build deps
[12:56] <dobey> so we have to rebuild in autopkgtests ot catch such breakage
[12:56] <pitti> dobey: yes, that's correct
[12:56] <dobey> which sadly apparently doesn't actually block the thing being uploaded from migrating to archive
[12:56] <dobey> but eh
[12:56] <pitti> (in some way it's also an abuse as it doesn't scale to the relatively few test machines that we have, but as long as not too many packages do it it's ok)
[12:57] <pitti> dobey: yeah, that bug got finally fixed yesterday
[12:57] <pitti> dobey: (not blocking stuff that causes regressions in autopkgtests)
[12:57] <dobey> yay
[12:57] <dobey> though now it matters much less for me, because no more u1 client
[12:57] <pitti> yeah, that was one of the most annoying/critical issues there and rendered the whole thing fairly useless
[12:59] <dobey> and if i could get beuno go give us proper oauth2 for sso, it would make life all that much better
[13:02] <beuno> but beuno hates nice things.
[13:03] <dobey> but it's so webby
[13:05] <beuno> dobey, I'll throw it into the developer pit next week, so what comes out
[13:07] <seb128> barry, coming to the upgrade testing call?
[13:10] <doko> Mirv, I didn't look how much in sync the qt5* packages are compared to Debian. But please could you make sure the symbols files are ok?  The Debian maintainer doesn't want to fix these before 4.9 is the default
[13:17] <barry> seb128: yes. sorry.  will try to get g+ working
[13:32] <nandersson> Hi, there seems to be a dependency problem in package samba-common-bin. Package has hard dependency: samba-common (= 2:4.1.6+dfsg-1ubuntu2), but there is already another package released internally with suffix version that breaks that dependency
[13:32] <nandersson> If dep was (>= .... it would surely work
[13:32] <nandersson> but as it is (= ... it doesn't
[13:40] <nandersson> If you run "sudo apt-cache show samba-common-bin | grep Depends" you'll see there are conflicting depends inside the package
[13:45] <cjwatson> nandersson: In what Ubuntu release, trusty or utopic?
[13:46] <nandersson> trusty
[13:46] <nandersson> I get error when realmd tries to install samba-common-bin (and it is strange becuase package is already installed)
[13:47] <cjwatson> nandersson: There's a samba-common-bin 2:4.1.6+dfsg-1ubuntu<IP_ADDRESS> along with the updated samba-common version, and that Depends: samba-common (= 2:4.1.6+dfsg-1ubuntu<IP_ADDRESS>)
[13:47] <cjwatson> So it looks fine to me.  Check that you don't have held packages or some other issue that's causing apt to hold back some of the upgrade
[13:48] <nandersson> When I run realm I get "samba-common-bin: Depends: samba-common (= 2:4.1.6+dfsg-1ubuntu2) but 2:4.1.6+dfsg-1ubuntu<IP_ADDRESS> is to be installed
[13:49] <cjwatson> Right, you're just restating what you said earlier :)
[13:49] <cjwatson> Try "sudo apt-get dist-upgrade" first and see what that says
[13:50] <nandersson> ...I have a couple of packages there - I'll try to install them.
[13:50] <nandersson> :)
[13:50] <cjwatson> Then "apt-cache policy samba-common-bin" should show 2:4.1.6+dfsg-1ubuntu<IP_ADDRESS> as the candidate version
[13:51] <nandersson> yes, it does
[13:59] <nandersson> It looks like it is PackageKit that reports the problem
[14:04] <nandersson> hrmm...I'll re-roll this one
[14:40] <kentb> if I want to pull in a bunch of recent security patches for a universe package (openwsman) is it best to open individual bugs for each one or can I incorporate them in one fell swoop?:  https://github.com/Openwsman/openwsman/commits/638b9c8acfa6ded84c94c01e137c61c29d65d62e/src
[14:40] <kentb> (this is for 14.04)
[14:41] <mdeslaur> kentb: file a bug, attach a debdiff to it, and then subscribe ubuntu-security-sponsors
[14:41] <mdeslaur> kentb: you can do them all in the same bug
[14:41] <kentb> mdeslaur, ok
[14:41] <kentb> cool. thanks!
[14:41] <mdeslaur> np
[14:48] <OdyX> tkamppeter: Did you see Debian's #748028 ? You probably want to fix that in cups-filters' upstream.
[14:57] <arges> tkamppeter: hi. can you add an SRU template to bug 1315864, so I can approve hplip? thanks
[15:21] <tkamppeter> arges, the SRU is not needed as separate SRU, as this problem was introduced to Trusty by the SRU of bug 1311697. There I have already announced that the SRU is broken and should not be tested and uploaded a corrected SRU package. So please approve that corrected package (hplip 3.14.3-0ubuntu3.2) into -proposed.
[15:22] <arges> tkamppeter: well the changlog indicates that it fixes both of those bugs 1315864 and 1311697, so does the changelog need to be corrected?
[15:24] <sil2100> dobey: hi! Could you take a look at this merge? It will fix some of the problems in the -proposed pocket: https://code.launchpad.net/~pitti/ubuntu-purchase-service/fix-ftbfs/+merge/219361
[15:25] <dobey> sil2100: done
[15:26] <sil2100> dobey: that was fast! Thanks
[15:28] <zequence> mapreri: I missed that mail. I'll have a look at it.
[15:28] <Saviq> xnox, just posted a current upstart assert in libnih: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1319083
[15:28] <Saviq> (still private)
[15:28] <dobey> slangasek: is https://bugs.launchpad.net/ubuntuone-storage-protocol/+bug/1307549/comments/2 acceptable as a test case? i'm not sure of a particularly good general test case for that though, "install current version and ensure ubuntuone-client connects to the server, install new version and ensure ubuntuone-client still can connect to the server" will work but doesn't point out a specific failure (as deployement of new cert on
[15:30] <tkamppeter> OdyX, for me this builds without warnings or errors on my 64-bit Ubuntu Trusty system, but anyway it is not correct to have two different types here. I will correct pdf.h to size_t to have them both the same. Thanks for the report.
[15:31] <tkamppeter> arges, this is because I have fixed it in Utopic first and then copied the changelog to the Trusty fix.
[15:32] <mapreri> zequence: thanks
[15:34] <arges> tkamppeter: ok. so trusty never had the problems shown in 1315864 since that package never made it past -proposed. So sounds like that bug should be removed from the changelog for the trusty upload.
[15:37] <tkamppeter> OdyX, cups-filters fixed upstream in BZR rev. 7203, which will make part of 1.0.54. How urgent is the fix, should I release 1.0.54 quickly?
[15:38] <OdyX> tkamppeter: no, doesn't seem to urgent. Pointing the bug to the fix would be nice though.
[15:45] <tkamppeter> arges, how to proceed then? Should I reupload with the wrong bug number removed (then you would need to reject the current 3.14.3-0ubuntu3.2 to make space for a corrected one) or will you simply put the current one into -proposed?
[15:48] <tkamppeter> OdyX, I have answered the bug report now.
[15:56] <bdmurray> ev: is there a design decision behind bug 1319099?
[15:59] <arges> tkamppeter: do you mind re-uploading with that bug number removed? I'll reject the current one. Thanks!
[16:03] <ev> bdmurray: commented - not by design
[16:04] <bdmurray> ev: thanks
[16:05] <ev> sure thing
[16:05] <ev> bdmurray: don't know if you saw, but Chipaca landed the imei code
[16:06] <tkamppeter> arges, no problem.
[16:10] <bdmurray> ev: no, thanks for that. How does recoverable_problem get called? Is it by an individual package?
[16:10] <tkamppeter> arges, package is corrected and re-uploaded now.
[16:11] <ev> bdmurray: as in generating a recoverable problem using that program? Yeah, any software can call it and feed report data over stdin
[16:11] <ev> ted has simplified this recently by adding support for it in libwhoopsie
[16:11] <ev> it's like we have a developer community for the error tracker :D
[16:11] <arges> tkamppeter: great! I'll review it when I see it in the queue.
[16:11]  * ted needs to finish the test for that…
[16:12] <ted> bdmurray, The code in that MR is used by a few projects already. You could look at url-dispatcher to see how it does it.
[16:13] <ted> bdmurray, We file a recoverable error on programs that send us bad URLs.
[16:13] <ted> (well, except for click packages. Someday. Someday.)
[16:14] <bdmurray> ted: I'd guess the whoopsie change needs fixing for bug 1316763.
[16:16] <ted> bdmurray, I'm not sure if that's wrong or right. Sometimes we want to see a problem across programs.
[16:17] <ted> bdmurray, I'd say it's displayed wrong though :-)
[16:54] <nandersson> Happy<PHONE_NUMBER> everyone!
[16:54] <nandersson> http://coolepochcountdown.com/
[16:55] <Unit193> Wow.
[16:56] <dobey> how is that a countdown?
[16:56] <nandersson> :D yeah
[16:56] <nandersson> should be a countup
[16:56] <ogra_> nitpickers
[16:57] <dobey> whoever owns that site should make it use a 32-bit int and make it an actual countdown to the end of time in 2038
[16:58] <dobey> and then have it restart at 0, like it's 1970 all over again, just like the mayan calander crushed our hopes and dreams
[17:01] <nandersson> haha :D Yeah, lots of people trying to solve the 2038-bug
[17:04] <dobey> i really just wanted to watch the chaos of the end of civilization in 2012. but alas. c'est la vie.
[17:36] <bdmurray> how can I manually set a hostname on a phablet?
[17:37] <bdmurray> I want to add something to /etc/hosts and its read-only
[17:38] <popey> bdmurray: interesting, i set the hostname on mine
[17:39] <bdmurray> popey: well its not really the devices hostname rather I want to map daisy.staging.ubuntu.com to a different ip
[17:39] <popey> oh ☹
[17:40] <popey> seems that might be a candidate for being in writable/
[17:40] <popey> ogra_: ^
[17:40] <bdmurray> I was going to manually try that but its read-only too :-(
[17:41] <ogra_> hmm
[17:41] <bdmurray> I mean /etc/system-image/writable-paths is read-only
[17:41] <ogra_> yeah, thats on purpose
[17:41] <ogra_> you would have to add the entry to the lxc-android-package ...
[17:43] <bdmurray> ogra_: do you have any other ideas?
[17:43] <ogra_> well, that would be the proper way ...
[17:44] <ogra_> for a quick hack: mouont -o remount,rw / ... make your changes ... mount -o remount,ro /
[18:12] <dobey> slangasek: btw, i see you accepted the ubuntuone-client into precise-proposed. can you also accept the one for saucy-proposed?
[18:44] <michagogo|cloud> If anyone who knows how to do Ubuntu packaging etc. has a few minutes and wants to do something small, Bug #1314616 would be a good choice.
[18:50] <sladen> michagogo|cloud: we'd probably prefer to follow whatever solution is made in Debian
[18:51] <sladen> michagogo|cloud: and so keep it upstream where possible
[18:52] <sladen> michagogo|cloud: there may also be better ways of solving the issue (a dummy package is one option; but there might be other solutions too)
[18:52] <michagogo|cloud> sladen: debian solves it by keeping the software in unstable only, where it can be updated
[18:53] <michagogo|cloud> In fact, the bitcoin package was already removed and blacklisted from syncing starting in trusty
[18:53] <ogra_> sladen, there was a related mailing list discussion on ubuntu-devel-discuss
[18:53] <ogra_> upstream asked for this ... packages will be maintained in a PPA by them instead
[18:54] <michagogo|cloud> sladen: Did you read the discussion I linked?
[18:54] <michagogo|cloud> (in the bug)
[18:56] <michagogo|cloud> ogra_: hm, was there a discussion on that ML? Got a link (or a date)?
[18:57] <michagogo|cloud> Also, the PPA has been around, maintained, and recommended for a long time
[18:57] <michagogo|cloud> But we still occasionally get people in #bitcoin trying to run 0.3.24 :-/
[19:06]  * sladen adds some high-level context
[19:17] <hjd> Hm... I saw that elementary failed to build on http://qa.ubuntuwire.com/ftbfs/, because it waits for libemotion-dev. That belongs to this source package (http://packages.qa.debian.org/e/efl.html) which seems to only be in Debian, not Ubuntu.
[19:18] <hjd> Though I can't find efl on the sync blacklist (http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt) or any other reason why it hasn't been synced. Does anyone know?
[19:35] <Unit193> Looked at the blacklist, and systemd-ui is on there.  Reason was that we use upstart and systemd unavailabile, which has changed in utopic.
[19:37] <hallyn> bdmurray: fwiw i'm aware there are a slew of sru's ripe for validation;  i'm hoping to spend time tomorrowm orning going through them (libvirt,cgmanager,kvm,and a kernel one at least)
[20:14] <Logan_> Unit193: I beat you to it :P
[20:14] <Logan_> Bug 1318776
[20:15] <Logan_> oh, and I could've answered hjd's question, but s/he left :(
[20:15] <Unit193> Logan_: Oh dang you!  Stinking snipers everywhere. ;)
[20:15] <Logan_> literally did it last night, haha
[20:15] <Logan_> I've been going through the blacklist and finding outdated stuff
[23:34] <sarnold> Laney: the ubuntu codesearch looks unhappy, "502 Bad Gateway" :(


[13:43] <holst> hi!
[13:43] <holst> i am trying to get nvidia and ati restricted drivers work from the installer
[13:44] <holst> I want the auto-detection to choose any of those two, and then and only then fall back to the free one
[13:45] <holst> Now I have this:
[13:45] <holst> xserver-xorg xserver-xorg/config/device/driver select nvidia
[13:45] <holst> that will probably not work so good with any other restricted driver, like ati :)
[14:12] <stgraber> holst: hmm, I guess you will need to create a script and have it called during the install
[14:13] <stgraber> because you can only install one of the two drivers (both cary libGL and only one can be installed at once)
[14:13] <stgraber> and then update the xorg.conf
[14:14] <stgraber> so basically have a script looking at lspci (best would be to use the same code as jockey to detect the best driver for the hardware), then installing the right driver and finally update xorg.conf
[14:17] <holst> hmm, not optimal...
[14:17] <holst>  would rather give a "priority list"
[14:19] <cjwatson> this is all up to the X packaging rather than the installer as such; you'd be better off asking its maintainers
[19:46] <holst> how do the big companies do this?
[19:46] <holst> how do they install ubuntu/whatever linux efficiently on heterogeneous computers?
[20:06] <hardwire> well paid admins
[20:06] <hardwire> :P
[20:10] <holst> that go around installing by hand? :)
[20:10] <holst> i generally think that peoplare are lazy
[20:10] <holst> and generally, stupid
[20:10] <holst> thats what I am anyway :)
[20:11] <hardwire> I'd guess most that can do the job are experienced enough to do it efficiently, whatever that solution may be.
[20:12] <holst> yes, but they solution is mostly ugly
[20:12] <hardwire> I'm not sure what we are arguing about anymore.
[20:12] <holst> I am saying: there must be a good way to do it
[20:12] <hardwire> and there probably is
[20:12] <hardwire> read up.
[20:18] <cjwatson> hardwire: um, that isn't terribly helpful
[20:18] <cjwatson> if you aren't prepared to understand users' problems, please let somebody else answer
[20:20] <cjwatson> I suspect, that said, that big companies doing this kind of thing either (a) buy hardware in bulk and therefore they're not all that heterogeneous, or (b) divide their installations into classes, each of which have distinct preseed files
[20:21] <cjwatson> there are a number of hooks available to preseed files that let you run arbitrary scripts during the installation
[20:22] <cjwatson> the best one to use here is probably dropping scripts into /usr/lib/post-base-installer.d/ - those are run after the base system has been installed, but before X is installed
[20:22] <cjwatson> so you can chroot into the target system and use facilities from there
[20:22] <cjwatson> it's not as neat as just specifying a priority list, but it would make it feasible
[20:24] <hardwire> I find myself identifying unique information between base installs, then imaging everything after creating a one-off script to set up that system as a unique machine.
[20:24] <cjwatson> so you could key your driver selection based on PCI IDs
[20:24] <cjwatson> the nvidia and ati vendor ids are well-known, and that's probably all you need
[20:25] <holst> can you use those scripts to feed more preseeing data as well?
[20:25] <cjwatson> yes
[20:25] <cjwatson> as long as they run before whatever's going to consume it, obviously
[20:25] <holst> hmm, that can actually solve both the xorg problem as well as the partitioning problem
[20:25] <cjwatson> the clumsy but simple way is to use the debconf-set utility; the neater but slightly longer way is to do '. /usr/share/debconf/confmodule' at the top of the script and then use db_set
[20:26] <cjwatson> (and possibly db_fset if you want to mark the question seen as well)
[20:26] <cjwatson> or you can feed preseed-file-syntax input to debconf-set-selections
[20:26] <cjwatson> partitioning is fiddly in hardy, unfortunately
[20:26] <cjwatson> you can do it, it's just awkward
[20:27] <cjwatson> you have to have a preseed/early_command script that writes out a second script in /lib/partman/display.d/ and makes it executable
[20:27] <cjwatson> in intrepid, there'll be a direct partman/early_command preseed to short-cut that
[20:27] <cjwatson> I might actually try to come up with something more generic
[20:27] <holst> yes, I will probably not be done with this before intrepid is released
[20:27] <cjwatson> main-menu/hook/<udeb-name>
[20:28] <cjwatson> (hypothetical)
[20:39] <holst> thanks very much for the advices; I have kept them in my /lastlog
[20:39] <holst> I think that using debconf-set-selections in a hook is the way I will go
[20:40] <holst> then I can make some fancy scripts that prove for a /NOBACKUP partition as well (my other problem)
[20:40] <holst> probe*


[11:51] <guiverc_t> possible 500 question:  when did the UWN start?  or for how long has it been going? (2006-may; i cheated & looked)
[14:38] <guiverc_t> fyi: unlikely useful: earliest reference (indirect) i found is in the official ubuntu book (2007 canonical) pg 315 - ubuntu news mailing list.  all prior books (i have) ~6.06lts were probably at editors before may-06 to know about it to list.
[14:40] <guiverc_t> ps: last statement was search in paper-book,  i find more fun than a search via startpage.com etc.


[15:20] <pevster> Hiya - not sure if this is the right channel but I have a question about how ubuntu deals with modules...?
[15:22] <pevster> I'm trying to build a custom version of a module thats normally in the kernel (can.ko) but not sure if there's a way under ubuntu to do it without re-building / re-installing the stock kernel?
[15:22] <pevster> Ideally UI'm looking for a pointer towards an existing example that I can just dissect ...
[15:40] <apw> pevster, you should be able to build against the "headers" in the normal way treating it as an out of tree driver
[15:40] <apw> of course if you have secure-boot in that environment you may have extra issues
[15:40] <pevster> apw: Thanks - nope, no secure boot here...!
[15:41] <pevster> apw: I also need to override a standard header, should that just work if I put my local include path ahead in the search?
[15:42] <apw> pevster, that i have not tried to do; i am rather spoilt as they builder i use for test builds takes 10m so i tend to just make a whole kernel
[15:42] <apw> pevster, though i would prolly just just ram over the one from the headers package as it is only used for these builds
[15:43] <pevster> 10m? My machine takes about 3 (!) :-O
[15:43] <pevster> For me it's more that I want to keep the ubuntu kernel standard and roll out the two modules onto stock test machines...
[15:44] <apw> yep i can see the use case :)
[15:44] <pevster> feels a bit dirty though :-D
[15:44] <pevster> not a fan of changing standard headers either but I can't see an alternate option...
[15:45] <apw> pevster, the headers an out of tree build uses are not /usr/include but only in /usr/src/* and only used for kernel module builds
[15:47] <pevster> Ah, thanks - I hadn't appreciated that! I'm used to normally just cross compiling whole kernels normally so this is a bit new!
[16:11] <jsalisbury> om26er, Upstream is requesting some data and testing of a set of patches.  I posted the requests to the bug report.
[16:12] <om26er> jsalisbury: yes, I replied to the bug. the latest kernel does not change anything and I have attached the logs
[16:12] <jsalisbury> om26er, great, thanks for the update.  I'll see what they want to do next.
[17:13] <pevster> apw: Thanks for your help ; got most of it working, but can't see how to force my clone of the header to take priority over the "proper" one -the "-I" flag doesnt quite cut it....
[17:14] <apw> pevster, i would just shove it into /usr/src over the top if it was me
[17:16] <apw> pevster, or like cp -lr /usr/src/<headers> to BUILD and then replace it in there, and build against that result
[17:17] <pevster> Hm... At the moment I've bodged it in the source by using a relative local path and defined the same protection var name to prevent the "proper" one getting included. A bit cludgey though
[17:27] <dgoulet> hi! so I'm having this problem since 4.8.y (vanilla) on Ubuntu with gcc 6.2.0-5ubuntu12:
[17:27] <dgoulet> Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong available but compiler is broken
[17:28] <dgoulet> whatever stackprotector I put, it fails with the same
[17:32] <apw> i think we specity gcc5 for the kernel build
[17:35] <dgoulet> hrm intersting... this is still failing: "make CC=gcc-5 -j4"
[17:35] <dgoulet> but could be the detection script
[17:39] <pevster> apw: Found it ; prepending LINUXINCLUDE
[17:53] <apw> pevster, sounds good
[18:17] <eagleeyes> infinity: what does dkms do?
[18:17] <eagleeyes> after the bcm kernel source package is installed does it need to have firmware cut?


[08:17] <sakre_> gotcha zequence  :)
[08:17] <sakre_> i'll be arround from off to on this week
[08:18] <sakre_> i'm still trying to find the link to the wiki with all the packages to go thru for desktop files..
[08:18] <sakre_> or did you guys finish that already?
[08:34] <zequence> sakre_: In the Plannin section of the wiki, there's a link to feature definitions
[08:35] <zequence> This is the feature definition page for multimedia application categorization https://wiki.ubuntu.com/UbuntuStudio/FeatureDefinitions/MultimediaApplicationCategorization
[08:36] <zequence> You'll find all the information and relevant links on that page
[08:50] <zequence> sakre_: Ok, to get back to the bug fix
[08:50] <zequence> I'll have you use a tool called edit-patch. I don't know it very well, but it can be used in this case, and it's very automatic.
[08:51] <zequence> I have a page about how to use it here, but I'm intending to change it later though: https://wiki.ubuntu.com/UbuntuStudio/StableReleaseUpdates
[08:51] <zequence> Start by cd'ing into the root of the ubuntu scribus bzr repo.
[08:52] <zequence> To start creating the patch: edit-patch missing-desktop-file-fix.patch
[08:52] <zequence> Wait until you get the prompt again. It will look different. edit-patch will be recording any changes you do to the branch now.
[08:53] <zequence> To fix the bug, all you need to do is to add one line int debian/scribus.install
[08:53] <zequence> The line is "usr/share/mimelnk/application/vnd.scribus.desktop usr/share/applications"
[08:54] <zequence> That's it. Now, you can stop edit-patch by doing Ctrl+D
[08:54] <zequence> debian/changelog will open automatically for editing
[08:55] <zequence> Use the page I linked to as reference on how to edit it. Change UNRELEASED to wily, and put "fixes LP: #1487031" inside the [] brackets
[08:56] <zequence> When asked to commit, answer no, since you still need to update the patch description.
[08:57] <zequence> I would not make this an upstream fix, since it's just one line.
[08:57] <zequence> So, with that in mind, try following the instructions on my page as well as you can, and also check here for information http://dep.debian.net/deps/dep3/
[08:58] <zequence> When that is done, you can now commit, but you do it manually with the command: debcommit
[08:59] <zequence> Then, you build, and test. Follow instructions on my page for how to do that.
[08:59] <zequence> Then, upload your branch. But, before you make a merge request, let me have a look at the branch, ok?
[09:03] <zequence> The reason why we do a patch here is so that any upstream change can easily be merged with the current branch, and the current patch can then be removed if not needed anymore.
[09:03] <zequence> I'm not sure your branch will be accepted - but if there is no other fix on the way, I don't see any reason why not.
[09:05] <zequence> btw, this is not a Stable Release Update. That only involves updating packages to a stable release. But, we use the same method pretty much in this case.
[09:20] <sakre_> thank you very much zequence i will go trhu all this, this afternoon.
[20:51] <sakre_> my robot didn't behave at the powerplant, so i couldn't do anything during afternoonLT. looking at it now.
[21:38] <sakre_> is there a reason why ctrl+alt+t is not opening a terminal in ubuntustudio? :)
[21:39] <sakre_> i know i can fix it shazambimbam, but there are so many tutorial which hints about it...
[21:39] <sakre_> hint about ctrl-alt-t for terminal
[22:55] <OvenWerks> sakre_: I have heard about that before. I think there is even a bug... But I can't find any aside from bug #1482181
[22:55] <sakre_> probably every body fixes it and forgets it :D
[22:55] <sakre_> i mean localy
[22:56] <OvenWerks> I do seem to remember it being discused in this channel or our mailing list though.
[22:56] <OvenWerks> sakre_: I would ask on the xubuntu channel how they set it up and we can copy it.
[22:57]  * OvenWerks has managed to convert one of his c apps to c++  :)
[23:00]  * sakre_ Y(^^)Yay
[23:00] <sakre_> hehe sorry, i meant it. congrats. i just forgot, its not a party place.
[23:01] <OvenWerks> I am in the process of taking something that used a terminal for output and using a GUI instead.
[23:01] <OvenWerks> http://www.ovenwerks.net/software/mcpdisp.html


[00:20] <mup> PR snapcraft#2694 opened: multipass: fix unexpected FileNotFoundError exception in setup_multipass <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2694>
[05:49] <mup> PR snapd#7376 closed: image,o/devicestate,seed: oops, make sure to clear seedtest helpers <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7376>
[05:51] <mup> PR snapd#7368 closed: cmd/snap,image,seed:  move image.ValidateSeed to seed.ValidateFromYaml <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7368>
[05:53] <mup> PR snapd#7373 closed: overlord/snapstate: revert track-risk behavior change and validation on install <Needs Samuele review> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7373>
[06:22] <mup> PR snapd#7377 opened: patch: add an overlord patch that normalizes channel in state <Created by mvo5> <https://github.com/snapcore/snapd/pull/7377>
[06:32] <mup> PR snapd#7372 closed: overlord/snapstate: revert track-risk behavior and change validation on install for 2.41 <Needs Samuele review> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7372>
[07:04] <mvo> hey pedronis ! good morning. I'm releasing 2.41 now (just fyi)
[07:10] <mvo> pedronis: also - 7067, should this go in or do you want to work on the feedback first?
[07:11] <pedronis> mvo: I'll work on feedback first, it's not urgent
[07:11] <pstolowski> mornings
[07:15] <mvo> pedronis: ok
[07:15] <mvo> pstolowski: good morning. thanks for your reverts
[07:16] <mvo> pstolowski: its all in and ready now, 2.41 should be in beta soon (just fyi)
[07:16] <pstolowski> mvo: sure, np!
[07:23] <zyga> good morning, sorry for being gone yesterday
[07:24]  * zyga jumps into coding
[07:33] <mup> PR snapd#7378 opened: release: 2.41 <Created by mvo5> <https://github.com/snapcore/snapd/pull/7378>
[08:23]  * pstolowski is doing some bug triaging
[08:46] <pstolowski> love this one https://bugs.launchpad.net/snapd/+bug/1829229
[08:46] <mup> Bug #1829229: league of legends snap crashes on entering in the game <snapd:New> <https://launchpad.net/bugs/1829229>
[08:54] <Chipaca> zyga: https://forum.snapcraft.io/t/hard-coded-absolute-paths/12987?u=chipaca
[08:54] <zyga> looking
[08:56] <zyga> thanks
[09:07] <zyga> brb
[09:08] <zyga> mvo: I fixed https://github.com/snapcore/snapd/pull/7370 - I'll push the fix after a run of local tests
[09:08] <mup> PR #7370: tests: fix ephemeral mount table in left over by prepare <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7370>
[09:08] <mvo> zyga: thanks
[09:38] <mup> PR snapd#7379 opened: tests: add version-tool for comparing versions <Created by zyga> <https://github.com/snapcore/snapd/pull/7379>
[09:39]  * zyga needs coffee
[09:40] <mup> PR snapd#7313 closed: many:  add the start of Core 20 extensions support to the model assertion <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7313>
[09:40] <pedronis> mvo: got John +1 ^
[09:41] <mup> PR snapd#7380 opened: debian: set GOCACHE dir during build to fix FTBFS on eoan <Created by mvo5> <https://github.com/snapcore/snapd/pull/7380>
[09:41] <mvo> pedronis: \o/
[09:51]  * zyga looks at https://github.com/snapcore/snapd/pull/7218
[09:51] <mup> PR #7218: tests: measure behavior of the device cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/7218>
[10:42]  * pstolowski lunch break
[10:52] <zyga> uh, soo hot
[11:09] <Chipaca> I like how go's testing package avoids 'testing.Testing' by just calling it 'testing.T'
[11:09] <Chipaca> what can I call mockbootloader.MockBootloader? :-)
[11:10] <zyga> Chipaca: could ve testing.It
[11:10] <zyga> Chipaca: mockbootloader.Bootloader seems more appropriate as a type though
[11:11] <Chipaca> mockbootloader.Er
[11:11] <zyga> oh oh
[11:11] <zyga> mockbootload.Er
[11:11] <zyga> ;D
[11:11]  * zyga hides
[11:11] <Chipaca> mockbootloader.WhoYaMockin
[11:11] <Chipaca> mockbootloader.YouTalkingToME
[11:11]  * Chipaca stops going down that one
[11:12] <mup> PR snapd#7381 opened: seed,image,o/devicestate: extract seed loading to seed/seed16.go <Created by pedronis> <https://github.com/snapcore/snapd/pull/7381>
[11:12]  * Chipaca commits the boring one and goes on to the next chunk
[11:13] <pedronis> that is a big PR
[11:14]  * Chipaca looks
[11:14] <Chipaca> pedronis: is there nowhere non-toplevel for 'seed'?
[11:15] <pedronis> Chipaca: is not new to that PR
[11:15] <pedronis> also it's fairly central
[11:15] <Chipaca> ah i hadnt noticed
[11:15] <pedronis> if we start worrying about top level packages
[11:15] <pedronis> I would do something about some other ones
[11:15] <Chipaca> i do :) but it's not a new worry
[11:15] <Chipaca> that's part of the reason for this refactor chunk
[11:16] <pedronis> anyway what I said
[11:16] <pedronis> Chipaca: we can have a chat about your worry (in general) at some point
[11:16] <Chipaca> k
[11:38] <zyga> hmmmm
[11:38] <zyga> mborzecki will be happy next week
[11:41] <zyga> woah
[11:41] <zyga> I'm so happy
[11:42] <zyga> mvo: I think by and large our cgroup woes are over
[11:43] <zyga> mvo: some actual work needed but conceptually we're going to have a good and clean way to handle our needs
[11:54] <ijohnson> morning folks
[11:59] <pedronis> ijohnson: hi, I'm pushing some small simplications to #7149
[11:59] <mup> PR #7149: cmd: add snap model command; daemon: add /v2/model, /v2/model/serial REST APIs <Remodel :train:> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7149>
[11:59] <ijohnson> hi pedronis
[11:59] <ijohnson> sounds good
[12:10] <pedronis> Chipaca: ijohnson: can you give a quick look at my last change to snap model: https://github.com/snapcore/snapd/pull/7149/commits/1a679f945673dd6a864a146f00908cffb1a4ddc8
[12:10] <pedronis> when you have time
[12:10] <mup> PR #7149: cmd: add snap model command; daemon: add /v2/model, /v2/model/serial REST APIs <Remodel :train:> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7149>
[12:11] <ijohnson> pedronis: sure I can look now
[12:11] <pedronis> ijohnson: I also tweaked separely api_model_test.go, please look what I did there
[12:12] <pedronis> fyi
[12:12] <ijohnson> ack
[12:14]  * Chipaca needs to go see about lunch
[12:21] <ijohnson> pedronis: reviewed, I think a couple comments around the test behavior would be helpful
[12:21] <ijohnson> I need to finish breakfast actually, bbiab
[12:26] <mvo> zyga: nice, great to hear
[13:41] <diddledan> why do I always read "ack" as "bah"-like, aka a moan or sign of annoyance, instead of "acknowledged"?!
[13:42] <roadmr> diddledan: it sounds to me like a bird skwawking or something
[13:42] <diddledan> ack
[13:42] <diddledan> :-p
[13:45] <roadmr> 🐦
[13:46] <diddledan> 🐧
[13:46] <roadmr> ohai tux
[13:46] <diddledan> :-)
[13:46]  * roadmr checks calendar... yup, it's Friday
[13:46] <diddledan> yey!
[13:47] <diddledan> two new streaming TV series that I've been anticipating have landed today! (Carnival Row on Amazon Prime in the UK at least, and The Dark Crystal on Netflix)
[13:48] <roadmr> dark crystal? nice!
[13:48] <diddledan> I guess my evenings are tied up for the foreseeable :-p
[13:48] <zyga> Chipaca: so
[13:49] <diddledan> The Dark Crystal Trailer: https://youtu.be/WwcvJTVnUgc
[13:50] <Chipaca> zyga: so
[13:50] <roadmr> thanks diddledan ! /me gets out his skeksis tunic and starts making chamberlain skwawks
[13:53] <zyga> Chipaca: I'll make something cold to drink
[13:54] <Chipaca> zyga: my main issue is I can't tell whether you're +1'ing with nits, or what
[13:54] <Chipaca> zyga: your review was wishy-washy :-)
[14:16] <diddledan> thinking about Netflix, makes me wonder what we're missing in the Chromium snap to support it. Amazon also complains.
[14:17] <zyga> Chipaca: +1
[14:17] <zyga> Chipaca: +2 even
[14:17] <zyga> Chipaca: we can  iterate, that's always better unless there's a clear bug in the  code
[14:17] <Chipaca> diddledan: does chromium work outside of the snap?
[14:17] <Chipaca> diddledan: i thought it was widevine
[14:17] <diddledan> I've not tried that
[14:17] <Chipaca> i.e. secret google sauce
[14:17] <diddledan> let me give it a go
[14:18]  * diddledan apt installs and gets confused at having two chromiums :-p
[14:18]  * Chipaca wins
[14:18] <zyga> Chipaca: I'm going for lunch now
[14:18] <Chipaca> zyga: buen provecho
[14:20] <diddledan> ok yeah, it fails outside, too
[14:20] <diddledan> hmm :-(
[14:21] <diddledan> @Wimpress get googlie onboard to publish the real chrome :-p
[14:21] <Chipaca> wooo
[14:21]  * Chipaca merges
[14:21] <mup> PR snapd#7185 closed: boot, etc.: refactor boot to have a lookup with different imps <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7185>
[14:21] <Chipaca> zyga: I'll address some of your concerns in the followup that i'm trying to wrap up
[14:24] <diddledan> interesting: https://packages.debian.org/stretch/chromium-widevine
[14:28] <pedronis> pstolowski: I did a high-level pass on #7355
[14:28] <mup> PR #7355: [RFC] interfaces/apparmor: load multiple profiles in a single batch <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7355>
[14:41] <mup> PR snapd#7378 closed: release: 2.41 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7378>
[14:41] <mup> PR snapd#7380 closed: debian: set GOCACHE dir during build to fix FTBFS on eoan <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7380>
[14:49] <zyga> Chipaca: sounds great
[15:02]  * Wimpress adds a task to my list for diddledan
[15:02] <pstolowski> pedronis: ty
[15:02] <diddledan> \o/
[15:02] <pstolowski> zyga: was this fixed / understood? https://bugs.launchpad.net/snapd/+bug/1832725
[15:02] <mup> Bug #1832725: snap refresh failure <snapd:New for zyga> <https://launchpad.net/bugs/1832725>
[15:03] <diddledan> Wimpress: my hero 😻
[15:03] <zyga> pstolowski: ah, yes
[15:03] <zyga> pstolowski: this is a dupe, let me find the other one
[15:04] <zyga> pstolowski: dedupped
[15:04] <zyga> thank you
[15:06] <pstolowski> ty
[15:17] <zyga> hmmm
[15:19] <mup> PR snapcraft#2690 closed: remote-build: error when --user is required <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2690>
[15:26]  * cachio afk
[15:26] <cachio> for lunch
[15:34] <zyga> quick update and reboot
[16:02] <popey> jdstrand: seeing conversations about printing popping up again. Can we please re-visit https://forum.snapcraft.io/t/inkscape-autoconnect-cups-control/8739
[16:02] <popey> (inkscape)
[16:03] <popey> 6 months later, no reply, and still complaints from users (and developers) that they can design something and then not print it.
[16:04] <ijohnson> pedronis: could you add your thoughts you shared this morning from SU to the forum topic on `snap model`: https://forum.snapcraft.io/t/remodeling-to-a-new-model/10477 ?
[16:05] <ijohnson> pedronis: I'm willing to keep sculpting at the output until it's what we want too
[16:06] <ijohnson> though I am now starting to think about this code as less of something that's built like a house and more something that's carved away like a marble michaelangelo sculpture :-)
[16:09] <roadmr> ijohnson: the sculpture is already there, you just have to chisel away the leftover chunks
[16:09] <ijohnson> exactly
[16:09] <ijohnson> I should start all PR's with 100000 lines of random chars and just whittle away the diff until I have a masterpiece
[16:11] <roadmr> ijohnson: meh just train an AI - these days, the artist would be replaced by some machiine learning on michelangel.io
[16:13]  * ijohnson considers buying michelangel.io and not michelangelo.io
[16:16] <roadmr> ijohnson: only because there's no .lo TLD
[16:18] <ijohnson> well also michelangelo.io is $3500/year and michelangel.io is only $45
[16:21] <roadmr> ouch
[16:23] <zyga> it's kind of crazy but the temperature is just right, now, to work :)
[16:26] <pedronis> ijohnson: I'll write something my monday morning there
[16:26] <ijohnson> pedronis: ack thanks
[16:27] <ijohnson> so am I good to merge PR #7149?
[16:27] <mup> PR #7149: cmd: add snap model command; daemon: add /v2/model, /v2/model/serial REST APIs <Remodel :train:> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7149>
[16:38] <Chipaca> ok peeps, i'm out for a while. Will probably be back later to wrap up. TTFN and have an awesome weekend if I don't see you!
[16:55] <zyga> ijohnson: thanks for the review, you found a bug indeed :-)
[17:32] <ijohnson> happy to help zyga :-)
[17:34] <zyga> ijohnson: updated https://github.com/snapcore/snapd/pull/7379
[17:34] <mup> PR #7379: tests: add version-tool for comparing versions <Created by zyga> <https://github.com/snapcore/snapd/pull/7379>
[17:34] <zyga> if you +1 this it would be my highlight of the day :)
[17:41] <ijohnson> looking now
[17:43] <ijohnson> zyga: +1'd
[17:43] <zyga> woot, thank you!
[17:43] <zyga> back to cgroups :)
[17:44]  * ijohnson takes a break
[18:02] <mup> PR snapd#7149 closed: cmd: add snap model command; daemon: add /v2/model, /v2/model/serial REST APIs <Remodel :train:> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7149>
[18:02] <pedronis> ijohnson: ^ I merged it
[18:04] <mup> PR snapd#7067 closed: overlord/devicestate:  support the device service returning a stream of assertions <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7067>
[18:54] <ijohnson> thanks pedronis
[20:01] <B|ack0p> hi
[20:02] <B|ack0p> everytime i boot into ubuntu 18.04 i face system error report popup
[20:02] <B|ack0p> error report doesnt give any detail but when i check the logs
[20:03] <B|ack0p> at the same time i received error report popup these are the possible errors/fails: https://termbin.com/xlo9
[20:03] <B|ack0p> Time is 22:54
[20:03] <B|ack0p> many errors like this:
[20:03] <B|ack0p> Aug 30 22:54:17 uthink-x61 gnome-software[3571]: Failed to load snap icon: local snap has no icon
[20:04] <B|ack0p> Aug 30 22:54:19 uthink-x61 gnome-software[3571]: Failed to load snap icon: local snap has no icon
[20:04] <B|ack0p> oh it is same sorry
[20:04] <B|ack0p> there are 7 same error log as above
[20:40] <mup> PR snapcraft#2695 opened: spread tests: install package marker into ament index <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2695>
[21:45] <jdstrand> popey: please note that there was nothing for me to reply to. the vote is cast. it was contentious. I asked for others to rule on it
[21:46] <jdstrand> popey: I did respond to today's posts
[21:46] <jdstrand> s/rule/comment/


[06:32] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3968 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[06:48] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3968 Needs building
[07:13] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3969 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[07:28] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3968 Successfully built
[07:35] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3969 Generating diffs
[07:36] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3969 Pending binary packages
[08:09] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3969 Successfully built
[08:41] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3961 Pending binary packages (focal/libvirt). Successfully built (focal/qemu)
[09:02] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3961 Diff missing (focal/libvirt). Successfully built (focal/qemu)
[09:37] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3968 Generating diffs
[09:48] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3968 Pending binary packages
[10:08] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3968 Successfully built
[11:03] -queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/3863 Ready to build (eoan/gcc-7-cross, eoan/gcc-7-cross-ports). Security pocket (eoan/gcc-7, eoan/gcc-8)
[11:10] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3968 Generating diffs
[11:29] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3968 Pending binary packages
[11:49] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3968 Successfully built
[11:53] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3878 Abandoning ticket
[14:46] -queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3970 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[15:30] -queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3970 Dependency wait (focal/s390-tools-signed). Pending binary packages (focal/s390-tools)
[15:50] -queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3970 Dependency wait (focal/s390-tools-signed). Diff missing (focal/s390-tools)
[16:10] -queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3970 Diff missing (focal/s390-tools). Pending binary packages (focal/s390-tools-signed)
[17:02] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3961 Diff missing (focal/libvirt). Uploading build (focal/qemu)
[17:22] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3961 Diff missing (focal/libvirt). Successfully built (focal/qemu)
[17:42] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3961 Diff missing (focal/libvirt). Pending binary packages (focal/qemu)
[18:02] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3961 Diff missing (focal/libvirt). Successfully built (focal/qemu)