[03:41] <Sam_> Hi
[05:22]  * Guest42341 such a beautiful day, today. great for science and such
[07:39] <liuxg_> where can find the output messages from a running snappy app? thanks
[08:11] <fgimenez> good morning
[08:19] <kgunn> stgraber: ping
[09:20] <mvo_> ogra_: you may need to rebase your livecd-rootfs ppa changes with my latest upload (should be trivial though)
[09:46] <ogra_> mvo_, will do (i hope i get done today, implementing this is hell ... (our chroot is so messed up after build due to removing half the packaging system))
[10:14] <JamesTait> Good morning all; happy Wednesday, and happy Stress Awareness Day! 😃
[14:20] <tedg> Oh man, I didn't send out stress awareness day cards. Now I'm stressed about it, but at least aware.
[14:24] <mcphail> Hi. Do we have a target date for the phone to transition to snappy?
[14:35] <mvo_> jdstrand: hey, just fyi - https://github.com/ubuntu-core/snappy/pull/55 is up mostly to get input from Chipaca but you are welcome to look/comment/reply of course
[15:04] <jdstrand> mvo_: ack, thanks
[15:24] <tedg> mcphail: No, there isn't a date set yet.
[15:31] <elopio> fgimenez: do you think subunit Status should return the number of bytes written?
[15:32] <fgimenez> elopio, doesn't feel quite well, maybe we could get rid of all the writer stuff
[15:32] <fgimenez> elopio, i think that the only useful part now is the multiwriter
[15:33] <elopio> fgimenez: I agree. Your pipes structure was cool, but now I don't find a use for it.
[15:33] <elopio> but before I get rid of it, I want to make sure that we would be able to put this subunit module in gocheck.
[15:33] <elopio> maybe I'll try that first before doing anything crazy on our branch.
[15:34] <fgimenez> elopio, ok makes sense
[15:47] <mcphail> tedg: thanks
[15:47] <stgraber> kgunn: pong
[17:35] <snappy_> getting a "UbuntuClientIntegration: connection to Mir server failed" error when trying to run mir app.
[17:35] <snappy_> any1 else run into this issue?
[18:19] <mvo_> jdstrand: I added the check for changes in "apparmor, ubuntu-core-security-*" around the snappy policygen --regenerate-all now, do you happen to remember if anything else is missing featurewise?
[19:02] <sergiusens> mvo_, is there a way to setup APT::Install-Recommends false using python3-apt?
[19:02] <mvo_> sergiusens: yes, apt.apt_pkg.config.set("apt::install-recommends", "false")
[19:03] <sergiusens> mvo_, neat
[19:03] <mvo_> python-apt is quite good :)
[19:04] <sergiusens> mvo_, it is :-)
[19:04] <sergiusens> mvo_, btw, did you figure out my question from the other day?
[19:05] <mvo_> sergiusens: uh, what was the question? about apt update files? sorry, I forgot again, could you help me?
[19:05] <sergiusens> mvo_, about having .fetch_archives tell me what it downloaded
[19:06] <sergiusens> or what it is about to download
[19:06] <sergiusens> mvo_, either is fine
[19:06] <mvo_> sergiusens: aha, so there is definitely a list of the urls in the acquire system, I just need to have a look how to access it
[19:08] <sergiusens> mvo_, great, this will allow me to download once per project if multiple parts require the same deb
[19:09] <mvo_> sergiusens: ok, so the best way is to create a "fetcher" via apt_pkg.Acquire(progress) and with fetch.list you can iterate over the list of items that got downloaded
[19:09] <mvo_> sergiusens: oh, if that is your use-case just use a common download dir
[19:09] <mvo_> sergiusens: apt will re-use existing debs, i.e. not fetch them again
[19:10] <sergiusens> mvo_, oh, but I need to unpack each to its own private location
[19:11] <sergiusens> mvo_, unless I just download once and unpack into the stage area and forget about putting it in part.installdir
[19:11] <mvo_> sergiusens: right, unpack them to any location, just keep the apt.Cache(rootdir=./something) to the same "something" for all parts
[19:11] <sergiusens> also a possibility; then we get the same phantom dep bugs as in debian packaging when using multiple parts masking missed deps :-)
[19:11] <mvo_> sergiusens: i.e. just keep the debs and the list in the same dir, unpack and handle in whatever way yu want
[19:12] <mvo_> sergiusens: well, you can of course iterate over a fetcher.items, each item will have a uri and a description
[19:13] <sergiusens> mvo_, ok, I'll look into it
[19:13] <mvo_> sergiusens: I will be off a bit, but just mail me any questions
[19:13] <mvo_> sergiusens: or telegram
[19:14] <sergiusens> thanks
[19:14] <jerryG> Chipaca: what changes need to be made to get sockets working with freerdp?
[19:33] <Chipaca> jerryG: I don't know; what isn't working?
[19:36] <jerryG> Chipaca: pastebin.com/ZvU8yFgL
[19:36] <Chipaca> jerryG: oooh, nice :)
[19:37] <Chipaca> jerryG: so, first, figure out what system call is being blocekd
[19:37] <Chipaca> blocked*
[19:38] <Chipaca> second, have your wrapper script set XKB_CONFIG_ROOT so it finds the xkb bits, if you need them
[19:38] <Chipaca> jerryG: but your first problem is that system call, clearly
[19:40] <Chipaca> jerryG: so. sc-logresolve is probably what you want. Or sudo journalctl | grep -i audit
[19:44] <Chipaca> jerryG: where do sockets come into it?
[19:48] <Chipaca> jerryG: also, do you need sudo?
[21:10] <tedg> zyga: I'm trying to run a single plainbox test in Snapcraft, do you know how to do that?
[21:34] <zyga> tedg: yes, one sec
[21:35] <zyga> tedg: have you seen ...
[21:35] <zyga> tedg: https://code.launchpad.net/~zyga/snapcraft/plainbox-app
[21:35] <zyga> tedg: (I need to return to that soon)
[21:36] <zyga> tedg: this allows you to do all of that
[21:41] <tedg> zyga: So I can't do it today?
[21:41] <zyga> tedg: with that example you can, with the current code it is also doable, just uglier
[21:41] <zyga> one sec
[21:42] <tedg> Why do we have all these custom wrappers? Feels weird this functionality isn't just provided as part of plainbox.
[21:42] <tedg> We shouldn't have code to support running the tool :-/
[21:43] <zyga> tedg: because it was written against old version that was in the archive
[21:43] <sergiusens> zyga, since you are here, can we have 'silent mode unless errors' for plainbox commands spitting output?
[21:43] <zyga> sergiusens: I believe exactly that is implemented in the branch above
[21:44] <zyga> tedg: plainbox is primarily a library and now it's very easy to create all kinds of tailored tools on top
[21:44] <zyga> tedg: like the one I wrote there
[21:44] <zyga> sergiusens: it runs tests and shows the error for each failing test
[21:45] <zyga> tedg: plainbox run -i regexp-matching-test-id
[21:45] <zyga> tedg: that runs a single thing
[21:46] <zyga> tedg: in integration_tests/runtests.sh you can see we call plainbox run -T $test_plan
[21:46] <zyga> tedg: you can run plainbox run -i blah manually
[21:46] <zyga> tedg: for quick testing that's actually pretty useful
[21:46] <zyga> tedg: you can run manage.py develop
[21:46] <zyga> tedg: then all of the snapcraft integration test cases are available directly
[21:46] <zyga> tedg: plainbox run -i test_id
[21:47] <tedg> zyga: Can you give me an example, that wasn't working for me.
[21:47] <zyga> tedg: sure, let's see
[21:52] <zyga> tedg: eh :)
[21:52] <zyga> tedg:  SNAPCRAFT=snapcraft plainbox run -i 2015.com.canonical.snapcraft::snapcraft/normal/bzr-tag
[21:52] <zyga> tedg: everything failed because $SNAPCRAFT was unset, it is set by the wrapper script
[21:52] <zyga> tedg: I think scripts could just default to ${SNAPCRAFT:-snapcraft}
[21:53] <zyga> tedg: or really make it always snapcraft and rely on PATH being set
[21:53] <zyga> tedg: but that's just script design
[21:53] <zyga> tedg: that worked for me _after_ I ran "./manage.py develop" to register the snapcraft integration testing tests with plainbox
[21:54] <zyga> tedg: actually running a provider "from source" is one of the last snapcraft driven APIs that I haven't improved, I have a branch for that but I haven't worked on it since holidays (overloaded with other stuff)
[21:54] <zyga> tedg: there's a branch that adds a provider unit so that manage.py becomes obsolete (apart from being a convenience for running stuff interactively)
[21:55] <zyga> tedg: and then plainbox run could take a path to the provider as an argument, to let it just run without any extra setup
[21:55] <tedg> Okay, I think that I was missing the ./manage.py develop step
[21:55] <zyga> tedg: and anther, unrelated, branch that adds environment units so that a job can sensibly depend on an environment variable and things like unset SNAPCRAFT won't have bad UX
[21:55] <tedg> I seem to get a test now.
[21:56] <zyga> tedg: I will return to them after I settle down in the snappy core team and start feeling some free time on Fridays
[21:56] <tedg> The test fails, but at least it runs :-)
[21:56] <zyga> tedg: hehe :)
[21:56] <zyga> stuff I've mentioned is in https://code.launchpad.net/~zyga/checkbox/config-units
[21:56] <zyga> and in https://code.launchpad.net/~zyga/checkbox/provider-unit
[21:58] <zyga> sergiusens: can you confirm my assertion
[21:58] <zyga> sergiusens: if there is something to actually do there I'd love to know
[21:59] <sergiusens> zyga, how far back do I have to read? I am all for not needing manage.py
[22:00] <zyga> sergiusens: just about the interactive output on error thing you asked about
[22:01] <sergiusens> zyga, if it is already there, that's fine; I recall it from Budapest now
[22:01] <sergiusens> zyga, ideally it would live in trunk/master ;-)
[22:01] <zyga> ::)
[22:01] <zyga> sergiusens: yeah, belive me, I wish I had 34 hours, not 24
[22:01] <zyga> sergiusens: catching up with family, checkbox, snappy and UOS now
[22:01] <zyga> sergiusens: and $commercial_project
[22:01] <zyga> sergiusens: fun
[23:02] <jerryG> Chipaca: no.  I don't need sudo to reproduce error.  DO u want me to send you journalctl output?
[23:03] <jerryG> Chipaca: sockets are used to connect w/ remote host