#ubuntu-autopilot 2014-06-16
<balloons> elopio, when you get a second I'd like to take quickly about some core apps tests; file manager, calendar, and reminders
<balloons> I'd like to talk :-)
<elopio> balloons: I have 7 minutes
<elopio> then meeting, and then back.
<balloons> elopio, let's talk in an hour and 7 ?
<elopio> balloons: ok.
<balloons> elopio, re: faking home stuff.. ping me before you start it again as there is even more file copying / symlinking that has to be done than is in calendar.
<elopio> balloons: ok. Can we have a sample app that will fail if we don't have all the folders?
<elopio> we will need that to automate a test and make sure it keeps working.
<balloons> elopio, sure.. that's something I can help with.. so just note we should work it together
<elopio> I have it noted.
<balloons> for now, back to other things :-)
<balloons> nuclearbob, :-)
<balloons> so I have a bug I shall ping you about nuclearbob until veebers and thomi arrive if you are interested and curious
<balloons> or perhaps cgoldberg as well
<balloons> https://bugs.launchpad.net/autopilot/+bug/1328600
<ubot5> Ubuntu bug 1328600 in Ubuntu Calendar App "test_new_event autopilot test fails on device (r315)" [Undecided,New]
<nuclearbob> balloons, I can try, cgoldberg may also be able to help
<nuclearbob> balloons, I expect maybe that's related to changes that thomi recently made, so it may be easiest to wait until he gets on
<balloons> so essentially the bug is with datepicker and autopilot; specifically autopilot is grabbing the max date.. and it's a twofold problem
<balloons> 1) overflow bug occurs for dates > 2038 and should be corrected
<balloons> 2) why is it generating the max date object?
<balloons> nuclearbob, I expected as much.. I was talking to thomi about the datetime stuff he did in Malta
<balloons> but he shouldn't get all the fun eh?
<nuclearbob> technically I think veebers is the kink of autopilot now, so he should get some fun too.  If I knew more about this particular change I could probably help better
<nuclearbob> *king
 * alesage imagines veebers wielding riding crop
<thomi> barry: good morning!
<barry> thomi: hi!
<thomi> barry: for the gunicorn packaging, I don't have a branch, but I assume that you can reconstruct my work from the package in the PPA? Or should I 'bzr init . ; bzr add *' and push somewhere?
<barry> thomi: iwbn if there was a branch.  also, where's the ppa?
<barry> thomi: https://blueprints.launchpad.net/pyramid/+spec/python3-pyramid
<thomi> iwbn?
<barry> "it would be nice" :)
<thomi> ahh
<thomi> gotchya
<thomi> ok
<thomi> one branch,c oming up.
<thomi> I'm actually somewhat proud of my gunicorn package, it doesn't seem *that* bad :)
<barry> :)
<barry> i have zope.deprecation and chameleon ready to go in debian
<thomi> barry: BP updated with branch & other details - thanks!
<barry> thomi: excellent, thanks
<thomi> barry: debian packaging is so nice when it "just works"
<thomi> I had to learn about refreshing quilt patches yesterday - so much fun!
<barry> thomi: quilt is so wonderful, especially when in a vcs.  it's like inception
<thomi> heh
<barry> thomi, nuclearbob could you please update the blueprint with the url to the ppa.  also, can i upload stuff to the ppa?
<thomi> barry: sure - I just added all the branch links...
<thomi> barry: I don't think you can
<thomi> but I can add you probably, one second
<thomi> barry: PPA link added, fginther is adding you to the CI team so you can upload
<barry> thomi: wow, it's a big ppa.  looks like maybe we should try again for porting restish to py3 eh? :)
<fginther> barry, done
<thomi> barry: yeah, they're using resting for other components
<barry> fginther: thanks
<barry> thomi: come to usa and we'll sprint on it :)
<thomi> barry: come to New Zealand and we'll sprint on it :D
<barry> thomi: clearly we need to convince our managers to split the difference.  see you in honolulu
<thomi> nah.... we should consider the total hours spent in a plane per year worked at Canonical, and whoever has the higher ratio gets to pick the location :P
<thomi> actually, I dunno, I may lose that
<thomi> barry: WRT the gunicorn stuff, do you think the correct solution is to ship a 'gunicorn3' executable? I ask because if we're going to keep that I need to update the charm
<thomi> barry: but if we're going to do something else then I need to hold off a bit I guess
<barry> thomi: the py2 version is `gunicorn` right?
<thomi> barry: correct
<barry> thomi: so yeah, gunicorn3 makes sense
<thomi> barry: and gunicorn_django and gunicorn_paster
<thomi> ok, sweet
<elopio> ping barry.
<elopio> https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-mako/1315/console
<elopio> it seems that your dialer py3 branch is still installing py2
<barry> elopio: huh
<barry> elopio: oh, i think that's because it depends on ubuntu-ui-toolkit-autopilot which pulls in both py2 and py3 dependencies
<barry> elopio: i just did a trunk merge and re-push
<elopio> ahh, you are right
<elopio> hum, so why did it fail again
<barry> elopio: that is a question i have never been able to answer
<elopio> Autopilot Package Version: 1.4.1+14.10.20140430-0ubuntu4
<elopio> could not import package dialer_app: No module named dialer_app
<elopio> Loading tests from:
<elopio> Did not find any tests
<barry> elopio: building the package locally just to see if the debs layout correctly
<barry> elopio: gosh, it looks okay to me.  i have nfc why the branch is failing
<elopio> barry: I think that now the problem is on phablet-test-run.
<barry> xnox: ^^
<elopio> this message at least is more readable than one week ago.
<barry> elopio: let's see what happens with my new push, although i'm sure it will fail again.  i can try to take a closer look tomorrow
<elopio> barry: oh, it is never installing py3.
<barry> elopio: dialer-app-autopilot Depends on python3-autopilot though
<barry> and ${python3:Depends}
<elopio> yes, then it's jenkins going crazy.
#ubuntu-autopilot 2014-06-17
<xnox> barry: hey
<xnox> barry: i'll check
<balloons> elopio, ping
<elopio> balloons: pong.
<balloons> elopio, seems mocking using the fixtures isn't working for me now.. still working for you?
<elopio> balloons: mocking what?
<balloons> elopio, sorry, mocking home.. I noticed it doesn't use a fake env on the desktop or device it seems
<elopio> balloons: the fixture sets the initctl and env vars, that can't stop working because we have tests to check it.
<elopio> but we are not using it on any app, are we?
<balloons> elopio, I use it on calendar, music, filemanager too maybe?
<balloons> elopio, I do remember it working, but something has changed as it's not atm
<elopio> I know filemanager is not using it. I don't know about the rest. Let me see...
<elopio> balloons: I think I'm not understanding what you are saying.
<elopio> calendar is not using the fake home fixture in trunk.
<elopio> it's using your original method, the one I copied to make the fixture.
<balloons> elopio, yes I'm saying the original method.. I just tried on the phone and I see other events in the calendar.. it can't be working
<elopio> balloons: ah, ok. I don't know about that. I haven't payed attention to that part while running the tests.
<balloons> alright, well if you haven't seen it, I guess I'll start by looking at the tests
<balloons> that show it's working :-)
<elopio> I think the calendar tests will pass even if they start with existing events.
<balloons> elopio, yes exactly
<balloons> however music won't, which is what I'm diving into now
<balloons> veebers, you about?
<veebers> balloons: sorry I missed your ping. I am now
<veebers> thomi: if/when you have a moment can you eyeball this please: https://code.launchpad.net/~veebers/autopilot/fix-upstart-rename-1330803/+merge/223486
<balloons> veebers, I'm concerned why my environment patching isn't working, and I'm trying to rule out autopilot.. or really trying to understand what's changed to make it no longe rwork
<balloons> specifically I'm attempting to patch what is considered HOME to get a clean enviroment
<veebers> balloons: so you had working code/patching and now it doesn't work?
<balloons> since phone brings more problems, I'm focused on the desktop for now, as it too no longer seems to work. In the past I used mock, then switched to fixtures.. It seems as of now, neither one works. Trying to confirm what the qml app sees atm, but it requires qt, so adding compiled code, blah
<balloons> veebers, simply put yes. It worked, but now it doesn't
<veebers> balloons: how are you currently patching the env?
<balloons> veebers, using fixtures;self.useFixture(fixtures.EnvironmentVariable('HOME', newvalue=temp_dir))
<balloons> that seems to work; in so much as if I log the environ variable after doing it, it's updated properly
<veebers> oops wrong button
<veebers> balloons: did I miss anything? last message I saw was: veebers, using fixtures;self.useFixture(fi . . .
<veebers> balloons: I would say that should work
<balloons> veebers, no I think you got everything
<balloons> veebers, I agree, so I'm confused as to why it's not
<balloons> and I'm not sure where the blame lies persay.. I also have another related question
<balloons> I see launch_dir as an arg option for test_launch_application but it complains when I try and add it as an argument
<veebers> balloons: what's changed between patching home working and not?
<veebers> interesting
 * veebers looks
<balloons> veebers, since this is across apps.. the only changes have to be on AP's side.. I guess I could backdate AP and see
<thomi> veebers: approved
<veebers> balloons: so if you're using fixtures with EnvironmentVariable none of that is autopilot
<veebers> thomi: cheers
<balloons> veebers, well technically I'm using the helper done by elopio
<veebers> ah ok
<balloons> veebers, so I would be happy to remove using that and call AP directly.. trying to narrow things down
<balloons> I see patch_enviroment is deprecated, but I tried using it also
<balloons> didn't change anything
<veebers> balloons: aye, patch_environment uses fixtures.EnvironmentVariable
<balloons> veebers, so part of the trouble is I can't verify that the app isn't seeing the patched env or not.. qml apps aren't friendly to printing these things afaik
<balloons> afaict, the patching from AP's side works.. then the app launches, and by all accounts, it isn't having the desired effect
<veebers> balloons: hmm one way to confirm this might be to write a simple qml app that has a text label that displays $HOME. Run that outside autopilot, then run that within autopilot (while patching the env)
<balloons> veebers, right.. however seems qml doesn't get access to such things.. So I'm trying to write a qt app that does it
<balloons> kind of annoying..
<thomi> balloons: launched how? Remember that some apps are launched in a clean environment
<balloons> veebers, any thoughts on the launch_dir issue however?
<thomi> for example if they're click / ubuntuapplaunch launched
<veebers> balloons: not yet, just going to look further now
<balloons> thomi, I'm using launch_test_application
<balloons> but launch_click_package seems to fail too
<balloons> although while we are on the topic.. I noticed there's ubuntuapplaunch and some others as well..
<balloons> ahh nvm.. it's a wrapper for upstartapplaunch
<balloons> kk
<thomi> balloons: upstartapplaunch doesn't exist any more
<thomi> it's ubuntuapplaunch now
<balloons> hmm.. I still have UpstartApplicationLauncher on my system
<thomi> balloons: oh, sure that still exists
<balloons> and I've upgraded... maybe this is why I'm seeing import errors for UpstartAppLaunch
<thomi> it's public API, so we can't change the name easily
<veebers> balloons: are you running T or U? I have a branch that I'm about to land that fixes Upstart -> Ubuntu app launch for T
<balloons> veebers, I'm on U.. the weird part is yea, on the desktop I can't use python2 autopilot without the import error
<balloons> but casting that aside, stay focused :-)
<veebers> balloons: :-) what's the complaint you see when trying to use launch_dir?
<balloons> veebers, http://paste.ubuntu.com/7660802/
 * veebers looks
<balloons> calling like so; http://paste.ubuntu.com/7660804/
<veebers> balloons: heh, yeah I can see the issue. It'
<veebers> s a bug :-\
<veebers> Will file and fix
<balloons> ok, good my sanity still exists.. I didn't see it in the arglist, but adding it didn't fix it
<veebers> balloons: but I don't have a straight forward answer for your HOME env var question  though :-\
<balloons> veebers, that's ok, I'm very close to getting the output from a qt/qml app
<balloons> so i'll have more data
<balloons> trolled; QML sees home as: $HOME
<balloons> veebers, sweet, so I got the env list
<balloons> veebers, and home shows correct.. so I guess you are safe on this front :-)
<veebers> balloons: heh sweet
<veebers> balloons: I was going to suggest: what happens when you launch $APP like: HOM=/tmp/blah <application> ?
<balloons> veebers, not a bad idea..
<veebers> but I guess you're getting some answers now
<balloons> well no.. I'm more confused that ever honestly
<balloons> it means everything is being set correct afaict, and the app has HOME set properly. But it completely disregards it
<balloons> so that means qmlscene or ?
<balloons> I really have no idea
<ahayzen> balloons, o/ is this the mediascanner2 issue?
<balloons> ahayzen, yes I'm trying to solve music's issue of not having a fresh enviroment
<ahayzen> balloons, you sure it is not something to do with mediascanner2 moving to use dbus to communicate
<balloons> to be fair I don't know anything at the moment
<balloons> since music isn't a compiled app it still might not be working
<balloons> and AP in general seems to be misbehaving for me now
<ahayzen> balloons, lol ... does autopilot stop/start mediascanner2 or something? i tried doing that manually one time but with no success
<balloons> ahayzen, no it doesn't.. I tried messing with mediascanner.. it's a ball of worms
<ahayzen> :/ that dbus move has caused chaos it was all working in Malta
<balloons> ahayzen, tests as well?
<balloons> I'll feel saner if so, haha
<ahayzen> balloons, yep end of Malta *everything* was working
<balloons> so what on earth changed to make the patching not work since Malta
<ahayzen> balloons, we were ready to land then mediascanner2 migrated to using dbus ...and that broke us with the app failing to start ... and then autopilot broke around the same time
<balloons> yes, but it's not just you.. all the patched apps don't mock properly anymore
<ahayzen> oh god thats not good
<balloons> I discovered that with calendar today
<ahayzen> but you got calendar working a few weeks ago?
<balloons> it still works, but the env is not clean
<ahayzen> ah
<balloons> for music you guys have to have a clean env
<ahayzen> yep
<veebers> balloons: I'm about to go for an early lunch, keep me in the loop with your env var findings. I should have a fix for the launch_dir stuff today
<balloons> veebers, will do
#ubuntu-autopilot 2014-06-18
<veebers> thomi: hey when you have a moment I would like to run something past you
<thomi> veebers: shoot
<veebers> thomi: recent changes to the application launch code (in AP) has introduced a docs / api difference: http://pastebin.ubuntu.com/7661258/
<veebers> in this instance the argument used to be expected to be named 'launch_dir' and currently states that in the docs, but the actual argument name in the method is 'cwd'
<veebers> considering that this code has already been released (although not that long ago) I'm considering just re-naming 'cwd' to be 'launch_dir' so that the docs and the arguments match up with what existed before this change
<thomi> are people hitting this as an API incompatibility?
<veebers> but that might trip up anyone who has recently read that docstring and is using cwd (as opposed to the developers who used launch_dir before this change)
<veebers> thomi: balloons is using launch_dir (as the docs state it's the thing to use) and it throws an exception (as its expecting 'cwd' instead)
<thomi> veebers: well, if you want to be super safe, ue both, but give a deprecation warning for the one you want to phase out
<thomi> you can then scan the test run logs for the warning and fix up any test suites that use the old one
<veebers> hmm, ok, that sounds better than just changing it back and letting people hit the error
<veebers> cool, that is the safest option I think. Cheers thomi
<thomi> nw
<veebers> thomi: I've changed my mind :-) I'll be running all the test suites as part of the autopilot release anyway. I'll remove 'cwd' put 'launch_dir' back in place, and during release testing I can scan the logs for any failing tests due to using 'cwd'
<thomi> veebers: that works as well
<veebers> coolio cheers. It's also much less typing ;-)
<thomi> barry: Are you around?
<veebers> thomi: do you have a moment for a quick question?
#ubuntu-autopilot 2014-06-19
<thomi> veebers: maybe, ask the question and I'll see if I can answer it :)
<veebers> thomi: sure, was just typing it : -)
<veebers> The upstart/ubuntu app launch change I made (so it works in trusty) causes an issue where if the import fails the logger now has a handler that outputs to stdout, meaning we get a bunch of unwanted logging
<veebers> so I currently have 2 solutions to this, but not sure which (if either) is best:
<veebers> http://pastebin.ubuntu.com/7666317/
<thomi> veebers: why is there logging code in that try/except block at all?
<veebers> thomi: I added that logging code
<thomi> why'd you add it in the try/except block? I don't understand what logging code has to do with the import statements
<balloons> veebers, btw on the logging stuff.. I've spent all day with the music devs.. we got it quasi working
<veebers> thomi: because when I step through the code before the "from gi.repository import UbuntuAppLaunch" the rootLogger has 0 handlers, after that import fails it has 1
<balloons> it required us calling the processes using subprocess copying the env, and copying it to upstart as well
<veebers> balloons: logging? Or this is using HOME right?
<balloons> sorry veebers not logging, but mocking :-)
<thomi> veebers: ahh ok, so UbuntuAppLaunch (or whatever it's called) adds a logging handler at import time.
<thomi> veebers: you shouldn't be removing it's logging handler at all, that's bad
<veebers> balloons: right :-) hmm, so your launching the application with launch_test_application
<thomi> veebers: instead, tweak the logging config so only 'autopilot.*' logs are produced, and everything else is unconfigured
<veebers> thomi: right, when it fails it adds a handler, the problem is then the rootLogger has a handler tha outputs all the INFO etc. messages
<thomi> the default should be to go to /dev/null
<veebers> thomi: ah right, thata's a much better solution
<thomi> veebers: only because we configured it that way
<thomi> and technically it shouldn't be the root logger
<balloons> veebers, yes but music at least uses a service which also has to be extensively lied to.. faked db, faked secondary service, upstart fakery, etc
<balloons> it got insane.. but it does work on the desktop now.. the device still doesn't work
<veebers> balloons: ah ok I see. Is there anything we can do within autopilot to ease that? (assuming this isn't a once off for one app etc.)
<balloons> i've no idea on calendar which doesn't have all that, and thus should be more straightforward.. but I guess I can't blame you ;-)
<veebers> heh :-) That's what I like to hear
<balloons> veebers, there might be some things we could look at, but my brain is way fried to think about it now
<thomi> veebers: yes - just configure logging for 'autopilot.*' loggers, not for all loggers.
<veebers> thomi: sweet, cheers I'll give that a whirl
<veebers> thomi: I may misunderstand this logging. UbuntuAppLaunch adds a handler to the root logger (i.e. logging.getLogger() ) so even if i use logging.getLogger("autopilot") it will 'inherit' that handler from root, right?
<thomi> veebers: are you sure that's what it's doing? It should be logging to a non-root logger (like 'ubuntuapplaunch')
<thomi> if so, then it's broken, and the proper fix should be submitted upstream
<veebers> thomi: I'm pretty sure it is, the log message "ERROR:root:Could not find any typelib for UbuntuAppLaunch" has :root: in it
<veebers> will dig further
<thomi> veebers: you'll probably want to look at the upstream source
<veebers> thomi: ack cheers. That probably means that autopilot logging should change too right? (something like changing logging.getLogger() -> logging.getLogger("autopilot") )
<thomi> veebers: logging.getLogger() doesn't get the root logger
<thomi> veebers: I'm like 90% sure it reads __name__ in the callers frame
<thomi> to figure out which loger you want
<thomi> or do we explicitly pass in __name__ most of the time? I can't remember
<veebers> thomi: from the docs for getLogger() If no name is specified, return the root logger.
<thomi> ok
<thomi> but we pass in __name__ most places in AP, right?
<thomi> cos I *know* we don't log to the root logger in AP
<veebers> thomi: we generally do "_logger = logging.getLogger(__name__)" but in run.py we use getLogger() (within the method def get_root_logger(): )
<thomi> TBH, it might make sense for AP to configure the root logger anyway
<thomi> since it's the application
<thomi> so that's probably still correct
<veebers>  we add handlers to the logging root
<veebers> yeah I see
<Noskcaj-school> FYI: In the xubuntu tests, __init__.py is a folder rather than a file.
<Noskcaj-school> I can fix this when i get home if noone does before then
<elopio> ping thomi: I need packaging help.
<thomi> elopio: yo
<thomi> wassup?
<thomi> elopio: Also, I thought you were on holiday?
<elopio> thomi: I'm on holiday on friday.
<thomi> ahhh
<elopio> thomi: I'm trying to package ubuntu_experience_tests through immitation, and failing miserably so far.
<thomi> heh, ok
<thomi> as luck would have it, I've just spent the morning packaging two python modules, so I'm "in the zone" :)
<thomi> have you got a branch I can look at?
<elopio> I'm lucky :) I'm pushing.
<elopio> thomi: https://code.launchpad.net/~elopio/ubuntu-autopilot-tests/skip_dialer/
 * thomi branches
<thomi> elopio: OK, first off, you need a setup.py file
 * thomi creates one quickly
<elopio> thomi: oh, I have one.
<elopio> I forgot to add it.
<thomi> :)
<thomi> let me know when I can re-pull :)
<elopio> thomi: done
<thomi> elopio: these are for python 3 only, right?
<elopio> thomi: yes. I'm commenting out the py2 dep while it gets ported.
<thomi> ok
<thomi> hmmm, for some reason the build step is being ignored
<thomi> ahaaaa
<thomi> elopio: got it going
 * elopio waits for the master to explain...
<thomi> pushing now
<thomi> elopio: lp:~thomir/ubuntu-autopilot-tests/skip_dialer/ works for me with 'dpkg-buildpackage' - I haven't tested 'bzr bd' but I see no reason why it shouldn't work too
<elopio> thomi: nice, so this doesn't use dh_python3, it uses pybuild right?
<thomi> elopio: yup: rule of thumb: if something's not working, try using pybuild :)
<elopio> thank you very much thomi.
<elopio> do you want to leave your approval here? https://code.launchpad.net/~elopio/ubuntu-autopilot-tests/skip_dialer/+merge/223671
<thomi> elopio: no worries!
<thomi> sure
<thomi> elopio: although you probably want to get someone who knows what they're doing approve it as well
<elopio> thomi: Right. I'll ask brendan or balloons tomorrow.
<thomi> elopio: approved, with a small tweak you should make
<elopio> thomi: sorry, what diff comment are you talking about?
<thomi> elopio: in the MP you just linked tome
<thomi> *to me
<thomi> I reviewed it, and made a diff comment
<elopio> yeah, I don't get what you are talking about.
<elopio> it might be because I should have EOD a couple of hours ago :)
<elopio> oh
<elopio> I see it, diff comments, this is the first one somebody leaves me :)
<elopio> thomi: one more thing, why did you commented the #Vcs-bzr line ?
<thomi> hmmm, I dunno - perhaps re-add that bit :)
<elopio> ok, thanks.
<elopio> tomorrow I'll ask ci to start running this suite.
 * elopio dreams about the future.
<elopio> barry: any chace you are still around?
<thomi> morning
<thomi> elopio: ping?
<elopio> thomi: pong
<thomi> elopio: kgunn & dednick were asking about whether there was an AP test that switched between applications
<thomi> i.e.- one that says "now load the XXX application"
<thomi> rather than randomly
<thomi> I wonder if you could follow up with kgunn and dednick about that?
<elopio> sure. Where?
<thomi> elopio: he asked me in #mir
<thomi> on canonical irc
<elopio> thomi: ok.
<thomi> barry: hey - got a second?
<barry> thomi: i'm on hold, so yes :)
<thomi> barry: was wondering if you saw my notes on the BP whiteboard, and if you had, wanted to say that I'm happy to take them through the mentors.debian.org process, but that since they depend on the new pyramid packaging, we'd need to wait for that to complete first
<thomi> barry: also, are you able to approve a package I have in the debian new/byhand queue? It's been there for several weeks now, and I'm getting impatient :)
<barry> thomi: i've got lots of the packages already in flight; taking a look at pyramid now, which requires a bit more hacking than nuclearbob's branch.  haven't looked at gunicorn or the debug packages
<barry> thomi: which packages in particular did you want to take through mentors?
<barry> um, no i am not an ftpmaster so i can't approve anything out of new ;)
<barry> thomi: as soon as python-nose-exclude clears new i can upload venusian
<thomi> pyramid-mako and pyramid-debugtoolbar. It wasn't so much that I *wanted* to take them through mentors, just that I was willing to, if it made your life easier :)
<thomi> barry: any idea how long it takes on average for something to get approved out of new?
<barry> thomi: ah.  since those are "nice to have but not blockers" i think i'm happy for you to do them :)  i've got other work backing up
<thomi> I see packages in that queue that have been there for over a year
<thomi> barry: ack
<barry> thomi: *usually* it's only a few days, but might be as much as a week or so.  i know some people i can poke if it goes too long, but i don't want to wear out my welcome so to speak ;)  i don't expect our packages to take too long
<thomi> well, my sphinxcontrib-youtube has been there for 3 weeks now :(
<thomi> I'm not in a rush since it's in ubuntu already, but it's annoying me is all
<barry> dang
<barry> thomi: https://wiki.debian.org/NewQueue
<barry> maybe some of those links will help getting it poked
<thomi> barry: thanks
<thomi> barry: heh, first words in the channel topic for #debian-ftp is "don't expect any service"
<thomi> which kind of sums up my experiences with debian in a nutshell
<barry> y'gotta love it
#ubuntu-autopilot 2016-06-22
<f1gjam> hey guys, I am trying to get autopilot to install and am having some trouble. First off, when I do openstack-install and the interface comes up, I enter all the details - everything seems to go fine then it fails. The log files under ~/.cloud-install/commands.log shows the following error:
<f1gjam> 400 BAD REQUEST ({"storage": ["Mount the root \'/\' filesystem to be able to deploy this node."]})\n', 'status': 1}'
<f1gjam> I also dont like the fact, when i cant copy and paste the API key in the openstack-install text UI aand have to enter it manually :(
<f1gjam> hey guys
<f1gjam> is there a configuration file for conjure-up openstack
<f1gjam> I hate having to manaully put in the API key
<dobey> wrong channel
<dobey> f1gjam: try #ubuntu-openstack
<dobey> see the topic
