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