[07:32] <doko> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/s/snapcraft/20181108_122554_7d4c2@/log.gz
[07:32] <doko> raceback (most recent call last):
[07:32] <doko>   File "/tmp/autopkgtest.P8IYeA/build.5xT/src/tests/integration/plugins/test_rust_plugin.py", line 107, in test_cross_compiling
[07:32] <doko>     self.assertThat(binary, HasArchitecture("aarch64"))
[07:32] <doko>   File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 498, in assertThat
[07:32] <doko>     raise mismatch_error
[07:32] <doko> testtools.matchers._impl.MismatchError: Expected 'aarch64' to be in ' x86-64'
[07:32] <doko> ----------------------------------------------------------------------
[07:32] <doko> Ran 26 tests in 2831.729s
[07:32] <doko> FAILED (failures=1, errors=1)
[07:32] <doko> autopkgtest [11:08:32]: test integrationtests-plugins: -----------------------]
[07:32] <doko> autopkgtest [11:08:33]: test integrationtests-plugins:  - - - - - - - - - - results - - - - - - - - - -
[07:32] <doko> integrationtests-plugins FAIL non-zero exit status 1
[07:48] <doko> zyga: ^^^ and armhf fails due to some cross compilation stuff
[08:31] <pitfd> test
[08:31] <pitfd> hi everybody, can somebody be of any help with the following question?
[08:32] <pitfd> when I install Firefox via snap infrastructure, will it touch home directory of my currently installed FF ESR?
[08:33] <pitfd> still running FF ESR 52 because of much needed adddon
[08:48] <doko> mvo: so snapcraft autopkg tests still fail trying to build some obscure rust code downloaded from the net, and due to some cross compile failure
[08:55] <mvo> doko: good morning! this is probably best discussed with sergiusens - but let me have a quick look, maybe something trivial could be done to unblock things
[08:55] <mvo> hey Chipaca ! good morning
[08:55] <Chipaca> mvo: hey! how're you doing?
[08:56] <mvo> Chipaca: good, thank you! had a nice and refreshing weekend
[08:56] <mvo> Chipaca: didn't play hockey for family reasons, that made me slightly sad
[08:56] <mvo> Chipaca: but otoh family  made me happy so a overall a net plus :)
[08:56] <mvo> Chipaca: and you?
[08:57] <Chipaca> mvo: :-)
[08:57] <Chipaca> mvo: I didn't play hockey either!
[08:57] <Chipaca> :-D
[08:57] <mvo> lol
[08:57] <doko> mvo: well, at least he's highlighted
[08:57] <Chipaca> mvo: but a good weekend, yes. Planning a break early december though.
[08:58] <mvo> doko: I think he got highlighted last week already :/
[08:58] <mvo> Chipaca: uh, I need to plan my break as well
[08:58] <pedronis> last week was the summit though
[08:58] <mvo> pedronis: aha, good point
[08:58] <pedronis> Chipaca: when?
[09:01] <Chipaca> pedronis: i've got 15 days to use-or-lose. Do you remember if it was 3, or 5 that could be carried over?
[09:02] <Chipaca> pedronis: in any case: the week from 3-7 december, for sure
[09:03] <mvo> doko: quite a few errors, I think I leave this best to sergio, I could disable some of the tests that look like upstream changes but other bits look like they have different causes :/
[09:03] <mvo> Chipaca: 5
[09:04] <Chipaca> mvo: ta
[09:04] <mvo> Chipaca: sounds like you will enjoy a long vac in dec then :)
[09:04] <mvo> Chipaca: good for you (not so good for us ;)
[09:04] <Chipaca> mbuahaha
[09:04]  * Chipaca takes all december off
[09:04] <Chipaca> (no)
[09:05] <mvo> fwiw 6127 needs a review, apparently this helps bringing a machine  back to life that got into a bad state by disabling a snap on arm that uses gpio
[09:06] <pedronis> mvo: it has so tests atm tough,  zyga said he was working on some
[09:06] <mvo> pedronis: :( ok, I can look at this, zyga is off today
[09:09] <pedronis> mvo: we also need to decide how to distribute the fix
[09:10] <Chipaca> pedronis: mvo: what's the bug?
[09:11] <mvo> pedronis: my understand is that putting it into the edge core is ok for now. then the user can snap refresh --edge core, snap enable affected snap and snap refresh --stable core
[09:11] <pedronis> Chipaca: gpio interface require some order dependency across the systemd and the apparmor backend for slot and plug
[09:11] <pedronis> seems we fix some part of that, but enable/disable of affected snaps atm is broken
[09:12] <Chipaca> ah
[09:12] <pedronis> mvo: ok, that assumes they are happy to try edge for this
[09:12] <pedronis> anyway we need on edge to start either way
[09:12] <Chipaca> reminds me, from the summit: we need a way to install a snap with its services disabled
[09:13] <mvo> pedronis: it does, we could use a hotfix branch, not sure if all the bits are in place for this though
[09:13] <pedronis> ?
[09:14] <mvo> pedronis: sorry if I was unclear, a store branch in a channel
[09:14] <pedronis> yes
[09:14] <pedronis> those are supported
[09:14] <pedronis> you mean building it on our side?
[09:14] <mvo> I think we have not used one for us yet
[09:15] <mvo> pedronis: yeah, we could take a stable core and do a one-off build for them, its a bit of work though (mostly because we need this for arm)
[09:15] <mvo> so not sure its really worth it
[09:15] <pedronis> as I said we need to ask
[09:15] <mvo> ok
[09:18] <mvo> Chipaca: I updated 6039 with your suggested error message (I think its a good choice)
[09:22] <Chipaca> mvo: over the weekend I was reminded of #1669000
[09:22] <mup> Bug #1669000: classic snap can't use confinement override <amd64> <apport-bug> <xenial> <Snappy:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1669000>
[09:24] <mvo> Chipaca: is jacknorriswebserver a classic snap?
[09:25] <mvo> Chipaca: we need to adjust our error message here, correct?
[09:25] <mvo> Chipaca: or is there more to it?
[09:25] <Chipaca> mvo: ignore the last comment, i think they're off piste
[09:25] <mvo> Chipaca: ok
[09:26] <Chipaca> mvo: it's very close to 6039, but from the other side
[09:26] <Chipaca> mvo: yes we probably should check and return a better error, like with --classic, but i'm not sure how current the problem is
[09:26] <Chipaca> i haven't tried
[09:26] <Chipaca> i just saw it, thought "oh that's similar to 6039" and went on with my weekend
[09:27] <mvo> Chipaca: heh, ok
[09:27] <pedronis> Chipaca: heh
[09:27] <pedronis> anyway doesn't sound super urgent
[09:28] <Chipaca> correct
[09:28] <Chipaca> talking about urgent, i'm off to epochs land
[09:41] <pedronis> Chipaca: let me know how that goes,  we should chat about how to do the further requests bit
[09:41] <pedronis> soon
[09:43] <Chipaca> pedronis: yep
[09:46] <zyga> hey
[09:46] <zyga> I'm off, just wanted to say a few words
[09:46] <zyga> I ran into some interesting bugs while reinstalling my devices
[09:47] <zyga> https://bugs.launchpad.net/snapd/+bug/1802773
[09:47] <mup> Bug #1802773: Cannot refresh from ubuntu-core 2.15.2 on raspberry pi "ubuntu core 16" image - snap-declaration for "snapweb": parsing assertion headers: expected 4 chars nesting prefix after multiline introduction "plugs:": "  network:" <snapd:Confirmed> <https://launchpad.net/bugs/1802773>
[09:47] <zyga> our stable images cannot update
[09:51] <zyga> with that I'm off to fix the printer
[09:51] <zyga> ttyl
[09:52] <pedronis> zyga: that's a store problem I think
[09:52] <zyga> yes
[09:59] <Chipaca> pedronis: the action context does need to carry epochs always, right?
[10:00] <pedronis> Chipaca: correct
[10:00] <pedronis> afaiu
[10:00] <Chipaca> pedronis: a lot of the test changes are going to remain ¯\_(ツ)_/¯
[10:01] <pedronis> oh well
[10:01] <pedronis> we still want the change
[10:01] <pedronis> saner api use
[10:08]  * Chipaca ~> afk
[10:12]  * Chipaca ~> really afk
[11:29] <ackk> Chipaca, hi, FWIW I filed https://bugs.launchpad.net/snapd/+bug/1802721 about that issue I'm having with bash completion
[11:29] <mup> Bug #1802721: bash-completion not working on core18-base classic snap <snapd:New> <https://launchpad.net/bugs/1802721>
[12:09] <pedronis> Chipaca: were snapshots done in 2.36 or will in 2.37 ?
[12:20] <cachio> mvo, hey
[12:21] <mvo> hey cachio
[12:21] <cachio> mvo, about beta validation
[12:22] <cachio> there were some issues on dragonboard
[12:22] <mvo> cachio: oh, tell me more please
[12:22] <cachio> mvo, first I saw this error
[12:22] <cachio> on 2 executions
[12:23] <cachio> same error
[12:23] <mvo> cachio: do you have a link to the error text?
[12:24] <cachio> https://paste.ubuntu.com/p/jZbsWd7x36/
[12:24] <cachio> next execution 13 tests failed
[12:24] <cachio> mvo, I am gonna debug nor
[12:25] <cachio> now
[12:25] <cachio> mvo, I go slow with the db because mine is broken so I am using a remote one
[12:25] <cachio> mvo, now I'll try to use mine with external display and usb keyboard
[12:26] <mvo> cachio: hm, Cannot access MTD device /boot/uboot/uboot.env: No such file or directory look scary
[12:26] <cachio> mvo, the rest of the devies are ok
[12:26] <cachio> mvo, yes
[12:26] <mvo> cachio: please check if /boot is mounted once you have a debug session
[12:26] <mvo> I check back after lunch
[12:27] <cachio> mvo, I could reproduce that in 2 different devices
[12:28] <cachio> mvo, sure
[12:28] <cachio> I'll continur with this
[13:03] <jamespage> sergiusens: o/
[13:03] <jamespage> sergiusens: does snapcraft support use of the before/after stanzas for daemon application startup ordering within a snap yet?
[13:03] <jamespage> or have I got the wrong end if the stick on that feature being implemented
[13:09] <pedronis> cachio: mvo: what were the errors during the weekend about snapd-vendor-daily?
[13:16] <cachio> pedronis, checking
[13:17] <cachio> pedronis, I dont see any error on snapd-vendor-sync
[13:17] <cachio> at least the spread cron branches worked
[13:18] <cachio> and all of them are in green
[13:18] <pedronis> cachio: I'm talking about the recipes on LP
[13:18] <pedronis> [recipe build #1985875] of ~snappy-dev snapd-vendor-daily-cosmic in cosmic: Failed to build
[13:18] <pedronis> etc
[13:19] <cachio> pedronis, ahh, ok, the recipe failed to build
[13:20] <cachio> I'll check that
[13:20] <cachio> I am gonna add a new spread cron branch to check the result of that recipe
[13:20] <cachio> currently we are just triggering but not checking the resutls
[13:25] <cachio> pedronis, seems to be a infrastructure issue
[13:26] <cachio> failed doing "git fetch"
[13:26] <cachio> on xenial and cosmic as well
[13:36] <Chipaca> ackk: yes that issue is true. For now, install core to get tab completion even if your snap is core18
[13:36] <Chipaca> ackk: #6126 addresses it
[13:36] <mup> PR #6126: dirs, wrappers, overlord/snapstate: make completion + bases work <Created by chipaca> <https://github.com/snapcore/snapd/pull/6126>
[13:37] <ackk> Chipaca, as noted in that LP bug, even with core it doesn't work
[13:38] <Chipaca> ackk: with core, it works
[13:38] <ackk> Chipaca, not in my case, see the bug
[13:38] <Chipaca> sigh
[13:38] <Chipaca> ackk: the bug just says "it doesn't work"
[13:39] <Chipaca> ackk: https://forum.snapcraft.io/t/debugging-tab-completion/4198
[13:39] <ackk> Chipaca, well, no also says I followed the forum thread, and everything except step 4 works
[13:39] <ackk> Chipaca, including the last step, if I load completion in the snap manually
[13:39] <Chipaca> ackk: ah sorry
[13:40] <Chipaca> ackk: I'd misread and misremembered it and just scanned it and jumped to conclusions and now I feel terrible and I'm sorry
[13:40] <Chipaca> give me a sec to recover and i'll walk through it with you in a moment
[13:40] <ackk> Chipaca, heh, np
[13:41] <Chipaca> ackk: for step 4, where's the -x output?
[13:41] <ackk> Chipaca, you want the full output or just the output of  compelte -P?
[13:42] <ackk> Chipaca, https://paste.ubuntu.com/p/wdfXH7yHcf/
[13:43] <mup> PR snapd#6128 opened: overlord/ifacestate: setup security backends phased by backends first <Created by mvo5> <https://github.com/snapcore/snapd/pull/6128>
[13:43] <Chipaca> ackk: right
[13:43] <Chipaca> ackk: so there's something missing
[13:43] <Chipaca> ackk: in that pastebin, see how the returned string points to a "cannot"
[13:43] <ackk> Chipaca, yeah but that's in the script
[13:44] <ackk> I mean that's not the output of complete, it's the script tha compares with "cannot"
[13:44] <Chipaca> ackk: so there _probably_ is a "cannot find completion specification for yadda.yadda"
[13:44] <Chipaca> hmm
[13:44]  * Chipaca looks
[13:45] <Chipaca> ackk: you're right
[13:45] <ackk> Chipaca, the problem I think is that complete -P only returns "default" and empty lines (as mentioned in the bug )
[13:45] <ackk> Chipaca, but if I run it in the --shell it works
[13:45] <ackk> (hence I was suspecting that --command=complete does something different
[13:49] <Chipaca> ackk: so
[13:49] <Chipaca> ackk: if you run snap run --command=complete sshoot 9 9 7 1 ' ' 'sshoot ' sshoot ''
[13:50] <Chipaca> ackk: what do you get?
[13:51] <Chipaca> ackk: because I get a clear indication of where the problem is
[13:51] <Chipaca> ackk: so I was wondering what you saw :-)
[13:57] <ackk> Chipaca, https://paste.ubuntu.com/p/tntr3dNtSW/
[13:57] <ackk> Chipaca, with multiple blank lines
[13:58] <Chipaca> gah pastebin is very slow here
[13:58] <Chipaca> not sure why
[13:59] <Chipaca> ackk: https://dpaste.de/jr9h
[13:59] <ackk> Chipaca, are you running on bionic?
[13:59] <Chipaca> ackk: no
[14:00] <ackk> Chipaca, that's another bug I filed, that mvo is fixing, classic bionic snaps don't work on xenial
[14:00] <Chipaca> ah this is the bad symlink thing?
[14:00] <ackk> yeah
[14:00] <Chipaca> mvo: is that fixed on core18 edge?
[14:00]  * Chipaca checks
[14:00] <Chipaca> i'm on edge
[14:00] <Chipaca> so probably no :-)
[14:01] <pedronis> Chipaca: standup? :)
[14:01] <Chipaca> gah, standup o'clock
[14:01] <Chipaca> pedronis: omw
[14:21] <Chipaca> ackk: so the next step would be to do the 'snap run --shell', and run etelpmoc.sh
[14:22] <Chipaca> ackk: which takes a lot of arguments, but it's got a comment explaining them
[14:22] <Chipaca> ackk: that's what 'snap run --command=complete' thing does, once it's 'inside'
[14:23] <ackk> Chipaca, /snap/core/current/usr/lib/snapd/etelpmoc.sh is not executable, is that right?
[14:23] <ackk> does snap run run it with "bash" ?
[14:25] <Chipaca> ackk: yes
[14:25] <ackk> Chipaca, https://paste.ubuntu.com/p/PYy443Xw9S/
[14:26] <ackk> Chipaca, note that if I actually source the sshoot-completion script inside a --shell, it works
[14:26] <ackk> Chipaca, why is it not found?
[14:26] <Chipaca> ackk: because I don't think the arguments are right
[14:26] <ackk> uhm
[14:26] <Chipaca> ackk: dunno
[14:26] <Chipaca> ackk: i'm technically in a meeting
[14:26] <ackk> I passed the same as the --command=complete, plus the completion script name at the beginning
[14:26] <Chipaca> ackk: half a neuron on this
[14:26] <ackk> Chipaca, ok sorry
[14:26] <Chipaca> :-)
[14:27] <Chipaca>     _die "USAGE: $0 <script> <COMP_TYPE> <COMP_KEY> <COMP_POINT> <COMP_CWORD> <COMP_WORDBREAKS> <COMP_LINE> cmd [args...]"
[14:28] <Chipaca> ackk: OTOH if the arguments are wrong, that'd be consistent with what it's seeing
[14:28] <Chipaca> dunno
[14:28] <ackk> Chipaca, is there a way to grab the actuall command that snapd runs?
[14:30] <Chipaca> ackk: let me look at the plumbing
[14:31] <ackk> Chipaca, found it from strace: /bin/bash /usr/lib/snapd/etelpmoc.sh /snap/sshoot/78/sshoot-completion 9 9 7 1 "sshoot " sshoot ""
[14:31] <ackk> Chipaca, this returns empty lines when run in the snap
[14:31] <Chipaca> ackk: was about to say, you just need the abs path on the completion script
[14:32] <Chipaca> ackk: time to bash -x it :-)
[14:34] <ackk> Chipaca, https://paste.ubuntu.com/p/xBZ6j7Gqvm/
[14:36] <Chipaca> ackk: could you copy etelpmoc.sh somewhere, and set -x after it sources bash-completion?
[14:37] <Chipaca> ackk: because at least I can't make sense of the whole thing :-)
[14:38] <ackk> Chipaca, https://paste.ubuntu.com/p/qGfvRhqVHR/
[14:41] <Chipaca> ackk: there's a problem with the complete -p call
[14:41] <Chipaca> ackk: +++ complete -p ''
[14:41] <Chipaca> ackk: that '' should be 'sshoot'
[14:42] <ackk> Chipaca, yeah but it's called with "$1" after a whole lot of shift's
[14:43] <Chipaca> ackk: ah!
[14:43] <Chipaca> ackk: you're missing a " " between the 1 and the "sshoot "
[14:43] <Chipaca> COMP_WORDBREAKS
[14:46] <ackk> Chipaca, https://paste.ubuntu.com/p/gHbdhWyxqW/
[14:47] <ackk> Chipaca, hold on, sorry, wrong arg
[14:47] <ackk> Chipaca, https://paste.ubuntu.com/p/yX6bdF29Kx/ should be the one
[14:48] <ackk> __python_argcomplete_run '' looks suspicious
[14:49] <mvo> ackk: the core18 thing should be fixed with core in edge (the bug you mentioned friday)
[14:49] <Chipaca> ackk: yes
[14:51] <ackk> Chipaca, because _python_argcomplete is called with no argument
[14:51] <ackk> it should get "sshoot" afaiu
[14:51] <Chipaca> ackk: try it -- you have all the args it gets
[14:52] <ackk> Chipaca, what should I try?
[14:52] <ackk> mvo, ah thanks
[14:53] <Chipaca> ackk: IFS=$'\v' COMP_LINE='sshoot ' COMP_POINT=7 COMP_TYPE=9 _ARGCOMPLETE_COMP_WORDBREAKS=' ' _ARGCOMPLETE=1 _ARGCOMPLETE_SUPPRESS_SPACE=1 __python_argcomplete_run ''
[14:54] <ackk> Chipaca, I need to source the completion file first right?
[14:54] <Chipaca> ackk: yes
[14:55] <ackk> Chipaca, ok, so that returns empty, if I pass 'sshoot' as argument, it returns the options
[14:55] <ackk> Chipaca, the first argument is the command
[14:55] <Chipaca> ackk: so why is that getting lost?
[14:56] <popey> degville: I'm trying to find a link at https://docs.snapcraft.io/snap-documentation/3781 which helps me help a developerrequest classic.
[14:56] <popey> degville: I have clicked everywhere I think, and can't find a doc, should that not be exposed?
[14:57] <ackk> Chipaca, IDK, that's snap's autocompletion I think
[14:58] <Chipaca> ackk: could you pastebin the script that's generated?
[14:58] <popey> degville: never mind, I'll file a bug :)
[14:59] <ackk> Chipaca, well actually it's basically what you see in the previous pastebin, those two __python_* functions
[14:59] <Chipaca> ah obvs
[15:01] <degville> popey: yes, it should be. The publishing side is next on my todo list (I promise)...
[15:01] <popey> :)
[15:01] <ackk> Chipaca, https://paste.ubuntu.com/p/rFVJpP84yn/
[15:02] <Chipaca> ackk: what happens if you add "$@" to $_compfunc ?
[15:03] <ackk> Chipaca, sorry, where?
[15:04] <Chipaca> ackk: etelpmoc.sh, after the $bounce check
[15:04] <Chipaca> $_bounce
[15:04] <ackk> Chipaca, that works
[15:04] <Chipaca> ackk: dammit
[15:05] <Chipaca> ackk: so I need to fix this, but you can fix it at your end as well
[15:07] <Chipaca> ackk: so if instead of calling the python generator you generate the script, and edit it to not need $1 but hardcode sshoot, it will work
[15:07] <Chipaca> ackk: also you'll avoid a python code in completion which will make it suck less :-)
[15:07] <ackk> Chipaca, sure, but that's bound to happen to any python script :)
[15:08] <Chipaca> ackk: oh, i'm fixing it, but it'll be a month at least before you get it in stable
[15:08] <Chipaca> ackk: OTOH I'd tell anybody using python there to stop :-)
[15:08] <ackk> why, argcomplete is so nice
[15:08] <Chipaca> ackk: agcomplete yes
[15:08] <ackk> you get autocompletion for free
[15:08] <Chipaca> ackk: i'm not saying don't use argomplete
[15:09] <Chipaca> ackk: i'm saying don't call python to generate a shell script that calls python
[15:09] <ackk> ah yeah I see, I can call it on snap build I guess
[15:09] <Chipaca> ackk: that will easily put you below the 200ms threshold of "fast"
[15:09] <ackk> Chipaca, why does this only seem to affect this case?
[15:10] <Chipaca> ackk: because most completion scripts don't look at $1 i guess :-)
[15:10] <Chipaca> _complete_potato doesn't check that it's called as potato
[15:10] <ackk> sure but if $1 isn't there, everthing is shifted  ?
[15:10] <ackk> ah you mean it's only using vars
[15:10] <Chipaca> ackk: no because everything the completer looks at is in COMP_ variables
[15:10] <ackk> ok
[15:10] <ackk> I see
[15:10] <Chipaca> exactly
[15:11] <Chipaca> I didn't even know bash passed $1
[15:11] <Chipaca> it's not like any of this is specced anywhere
[15:11] <Chipaca> :-)
[15:11] <ackk> Chipaca, ok, thanks for the help debugging, I'll workaround it
[15:11] <Chipaca> i'll push a fix in a bit
[15:11] <ackk> Chipaca, it makes sense, if you have multiple commands that use the same completion
[15:11] <Chipaca> first i'll get a cuppa tea and i'll turn on the heating because somebody turned off the sun
[15:11] <ackk> I see how it's not widely used
[15:24] <cachio> mvo, this last run is running well on dragonboard
[15:24] <cachio> mvo, perhaps we need to build our image in another way
[15:25] <cachio> instead of using beta channel
[15:25] <mvo> cachio: interessting, what did you change?
[15:25] <cachio> in general
[15:25] <cachio> we can use just core from beta
[15:25] <cachio> an the rest from stable
[15:25] <cachio> mvo, it is a new image
[15:27] <cachio> mvo, do you know if there was any change for the kernel snap?
[15:30] <cachio> mvo, I am havin lunch
[15:30] <cachio> I'll research a bit about the diff on the images
[15:31] <cachio> to see what could happen
[15:31]  * cachio lunch
[15:37] <mvo> cachio: not sure, let me check if the kernel has changed recently
[15:38] <pedronis> niemeyer: here's the discussion I mentioned about service order: https://forum.snapcraft.io/t/cross-snap-service-ordering/8319
[15:38] <mvo> cachio: one week and 5 days ago was the last upload
[15:57] <mup> PR snapd#6129 opened: data/completion: pass documented arguments to completion functions <Created by chipaca> <https://github.com/snapcore/snapd/pull/6129>
[15:57] <Chipaca> ackk: ^
[15:57] <ackk> Chipaca, nice, thanks
[15:58] <Chipaca> ackk: a big difference that makes argcomplete's eval(<some python>) approach slow with snaps is that the whole environment is discarded every time
[15:58] <Chipaca> ackk: whereas outside of snap you'd only do the eval the first time you tap tab
[15:58] <ackk> Chipaca, sigh, I was trying to put the generated completion file in snap/local, but snapcraft looks for it before actually filling snap/
[15:58] <ackk> Chipaca, ah yeah I had noticed completion was slow
[15:59] <Chipaca> ye
[16:02] <sergiusens> jamespage: you can use passthrough. I would explain more but I am sitting on a plane waiting on news on my diverted flight due to failed landing
[16:05] <ackk> is there a way to access the snap/ dir (IOW $PWD/snap from where "snapcraft" is run) inside a part?
[16:13] <mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37
[16:14] <mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37
[16:17] <ackk> Chipaca, got it working with the generated shell completion
[16:17] <Chipaca> ackk: woo
[16:17] <Chipaca> ackk: any faster?
[16:18] <ackk> Chipaca, can't really tell 'cause I haven't been using the old one, but it seems fast enough
[16:19] <Chipaca> ackk: fair enough
[16:20] <Chipaca> ackk: next you may want to look into whether passing some of the don't-load-site-libaries options still works and speeds up your python, or not
[16:20] <Chipaca> ackk: in the http snap I found it sped things up by quite a bit
[16:20] <Chipaca> (but i had to fiddle with sys.path in the script)
[16:22] <ackk> mvo, in which core18 version is the ldd link fixed?
[16:22] <ackk> I still see it broken in edge
[16:22] <ackk> (449)
[16:23] <mvo> ackk: yeah, its not merged yet, I was hoping for a review from foundations. if there is none by tomorrow I will merge, could you please remind me in our morning again?
[16:24] <ackk> mvo, ah I see, I thought it was pushed to edge already
[16:24] <ackk> mvo, sure, thanks
[16:24] <mvo> ackk: this fix is not, just the other one in core when there "core18" only and no core (the fix for the configure script)
[16:25] <ackk> mvo, oh, that one, I see
[16:36] <cachio> mvo, I am making some tests to see how it works changing the way we create the image
[16:37] <mvo> ok
[16:40] <cachio> mvo, because the test process is the same, what could change is the image we use
[16:41] <cachio> mvo, or testflinger is having some troubles to build the image
[16:41] <cachio> but no error shown in the logs
[16:43] <mvo> cachio: hm, thanks. is it worth checking with plars  if there might be any testfilinger issues?
[16:45] <plars> cachio: we don't typically build images, we install them from url
[16:46] <plars> cachio: I'm happy to try it out if you email me some info though... I'm sprinting right now though, so email preferred since it's 12:30am
[16:47] <cachio> plars, sure
[16:48] <cachio> plars, I'll write an email
[16:53] <mup> PR snapd#6130 opened: snap: make Epoch's MarshalJSON not simplify <Created by chipaca> <https://github.com/snapcore/snapd/pull/6130>
[16:53] <pedronis> mvo: mmh, we are getting timeouts in travis, for example your #6039
[16:53] <mup> PR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
[16:54] <mvo> :/
[16:56] <cachio> pedronis, mvo checking
[16:56] <pedronis> cachio: thx
[16:56] <cachio> pedronis, mvo it is the opensuse issue I mentioned on friday
[16:57] <cachio> I was trying to update it today but still getting some errors
[16:57] <cachio> pedronis, in case I can't create a new image today I'll move to manual until it works again properly
[16:57] <pedronis> thanks
[16:57] <cachio> np
[17:02] <mup> PR snapd#6131 opened: store:  remove unused currentSnap and currentSnapJSON <Simple 😃> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6131>
[17:04] <mup> PR snapd#6132 opened: many: some small doc comment fixes in recent hotplug code <Created by pedronis> <https://github.com/snapcore/snapd/pull/6132>
[17:17] <mvo> zyga: for tomorrow - I pushed a spread test for 6128 (the gpio bug). it hopefully simulates things good enough, fails on master (so triggers the bug), I'm waiting for the successful run and will check after hockey
[17:26] <cachio> mvo, last run on dragonboard passed
[17:27] <cachio> it is running on my device
[17:27] <cachio> the diff as I said the the source image
[23:30] <mup> Bug #1803002 opened: Multiple SELinux alerts on install / uninstall on Fedora 29 <Snappy:New> <https://launchpad.net/bugs/1803002>