[00:44] <Son_Goku> oh man
[00:44] <Son_Goku> you've got to be kidding me
[00:45] <Son_Goku> mvo forked the golang seccomp bindings? :(
[00:45] <Son_Goku> is there a chance of a happy re-merge?
[00:46] <Son_Goku> oh wait, this fork is trivial
[00:46] <Son_Goku> it's just to do weird things with old libseccomp
[01:21] <mup> PR snapd#3577 opened: packaging/fedora: Fix build for snapd <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3577>
=== chihchun_afk is now known as chihchun
[07:07] <mup> PR snapd#3500 closed: store: talk to api.snapcraft.io for assertions <Created by cjwatson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3500>
[08:23] <lukav> hello
[08:25] <lukav> is it possible to deploy a single out of tree built kernel module inside a snap? without making a kernel snap?
[09:08] <Chipaca> lukav: I don't think so, but maybe?
[09:15] <Chipaca> lukav: I mean, it's not supported as far as I know, but it might be possible
[09:22] <lukav> Chipaca: there is a kernel-module-control interface in the reference, but I don't know if I need to load the module by a custom script or snap can be configured to do that automatically
[09:25] <Chipaca> lukav: yes. But can that interface be used to insmod things from your snap?
[09:26] <Chipaca> lukav: how would you support the different kernels?
[09:30] <lukav> Chipaca: I will have to try insmoding it, not sure how to go about different kernel version support
[09:31] <Chipaca> lukav: what are you trying to do?
[09:32] <lukav> Chipaca: I'm trying to use a camera that requires patching the uvc kernel module
[09:33] <Chipaca> lukav: it sounds like you're building a device / gadget / thing
[09:34] <lukav> Chipaca: it will probably end up as a custom ubuntu core device image, but I'm trying to explore my options
[09:35] <Chipaca> lukav: if your end goal is to have something like a device, you'll presumably be able to control the kernel, so that part'd be fine
[09:35] <Chipaca> control as in decide which one gets installed, not necessarily roll your own
=== gurmble is now known as grumble
[09:36] <Chipaca> the kernel-module-control interface is manually connected, but it'd probably work for development
[09:37] <Chipaca> lukav: give it a try and let us know how it goes :-)
[09:38] <lukav> Chipaca: I was initially thinking to have both options, have a snap of my application that can provide the option to access that type of camera by loading a custom uvc kernel module, and a custom device image with the required kernel and application snaps installed
[09:40] <lukav> Chipaca: sure, thanks for the info
[09:45] <mup> PR snapd#3578 opened: store: talk to api.snapcraft.io for purchases <Created by cjwatson> <https://github.com/snapcore/snapd/pull/3578>
[10:02] <pstolowski> Chipaca, +1 on #3554 with two very minor comments
[10:06] <Chipaca> pstolowski: yep, was responding to one of 'em
[10:08] <Chipaca> pstolowski: you mean to say you don't think having png image data in the journal is useful?
[10:08] <Chipaca> pstolowski: I don't know what you're talking about
[10:08]  * Chipaca sends an mp3 too, for good measure
[10:08] <Chipaca> "this is what the server sounded like as it was dying"
[10:09] <pstolowski> Chipaca, I mean numbers vs strings
[10:09] <Chipaca> i know, i know
[10:09] <Chipaca> as i say, that's fine; they're always strings (or []bytes, and then i suddenly honestly don't care)
[10:09] <Chipaca> without a clear non-nonsense use case, i shall continue not caring
[10:15] <mup> PR snapd#3576 closed: tests: snap debug confinement does not exists yet in 2.26.x <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3576>
[10:18] <mup> PR snapd#3579 opened: snap-seccomp: link libseccomp statically to snap-seccomp <Created by mvo5> <https://github.com/snapcore/snapd/pull/3579>
[10:21] <pstolowski> Chipaca, that's fine. it was just to check if you are aware of any actual numbers there and if you aren't, that's ok
[10:44] <zyga> test...
[10:44] <zyga> \o/
[10:44] <zyga> mvo: are you reading this?
[10:52] <Chipaca> zyga: I don't know if mvo was, but I was reading it
[10:53] <zyga> Chipaca: yay!
[10:53] <zyga> so I *may* have working multi-homed network now
[10:53] <zyga> on an old sempron class PC
[10:53] <zyga> (screw you arm)
[10:53]  * zyga had a very long night
[11:03]  * zyga shuts the whole network contraption and moves it to the desired location
=== chihchun is now known as chihchun_afk
[11:33] <Saviq> davidcalle, hey, any word on https://developer.ubuntu.com/snappy/guides/mir-snaps ?
[11:59] <zyga> whee
[11:59] <zyga> desk assembled
[12:03] <ppisati> ogra_: edge was still running pi2-kernel #30 when #34 was available, so i released #34 in edge
[12:04] <ppisati> ogra_: now i found a problem with it, if i release #30 back to edge to i cause breakage or what?
[12:04] <ppisati> *do i
[12:04] <ogra_> ppisati, thanks ... while i'd really like us to keep edge for manual uploads when testing stuff, we shouldnt exclude it from the auto uploads ... i wonder if thats possible in one of brads scrips
[12:05] <ogra_> ppisati, if you release 0 it should update (well, actually downgrade) again
[12:05] <ppisati> ogra_: 0?
[12:05] <ogra_> *if oyu release 30 (sorry brokwn 3 here)
[12:05] <ppisati> ogra_: ok, me tries
[12:06] <ogra_> what was the prob ?
[12:06] <ogra_> if the boot fails it will auto-rollback anyway
[12:06] <ogra_> if it is more subtle like a broken driver it wont indeed
[12:07] <ppisati> ogra_: no, the dtb overlay files had the wrong extension (.dtbo)
[12:07] <ogra_> ah
[12:07] <ppisati> ogra_: well, actually that's the correct extension, it's just that our bootloader is old and doesn't know it
[12:07] <ogra_> we shoould update it then :)
[12:07] <ppisati> ogra_: so first i fix that part, than i update the bootloader in the archive, test everything, then we can revert this fix and pick the new bootloader tpgether
[12:07] <ogra_> so at least with fresh images from edge you get the right thing
[12:08] <ppisati> ogra_: actually, it didn't break anything because daily images still had the overlay from #30 in /boot/uboot/overlays/
[12:08] <ogra_> i need to re-work the whole gadget stuff anyway ... ondra did the dragonboard already, but pi is still behind
[12:08] <ppisati> ogra_: but if i didn't roolback it, i would break overlay in today's daily
[12:08] <ogra_> (make it build from upstream u-boot and all )
[12:09] <ppisati> ogra_: yes, the gadget update part is really important for us
[12:09] <ppisati> ogra_: in stable we are still shipping an old kernel with known vulnerabilities
[12:09] <ogra_> well, the update bit is the jjob of the snapd team ...
[12:09] <ogra_> i'll adjust the gadgets to use it but first i need the infrastructure
[12:10] <ppisati> ogra_: ack, anyhow, the rollback worked
[12:10] <ppisati> ogra_: so now i can got get some lunch and later fix this overlay rename thing
[12:10] <ppisati> ogra_: ta
[12:10] <ogra_> ppisati, right, that is why the blobs and dtbs should in the future be shipped with the kernel snap
[12:10] <ppisati> ogra_: did you see this?
[12:10] <ogra_> and be copied in place ....
[12:10] <ogra_> see what ?
[12:11] <ppisati> ogra_: ah crap, it wasn't pushed yet, hold on
[12:12] <ppisati> ogra_: here is for the dragonboard - 4833c0343531aee507e80771c83c086da7488a71
[12:12] <ppisati> ahhhhhhhh
[12:12] <ppisati> ogra_: https://patchwork.ozlabs.org/patch/780737/
[12:12] <ppisati> ogra_: and here is for the raspi2 - https://patchwork.ozlabs.org/patch/781277/
[12:13] <ppisati> tought for the raspi2, we need the wireless package to enter the archive
[12:13] <ppisati> it builds on LP though, but it'll break locally
[12:14] <ogra_> because we cant force PPAs
[12:14] <ogra_> you could add a "prepare" scriptlet that downloads the deb and uses dpkg -x or so
[12:15] <ogra_> (nice btw)
[12:16] <ogra_> (or simply add an extra part that pulls it from the upstream github branch)
[12:16] <ogra_> (it is just binary firmware after all)
[12:19] <ppisati> ogra_: me goes out for lunch, we can discuss about it later again
[12:19]  * zyga breaks for lunch and will catch up with everyting
[12:57] <mup> PR snapcraft#1402 opened: Better explain dependency link processing <Created by evandandrea> <https://github.com/snapcore/snapcraft/pull/1402>
[12:58] <mvo> fgimenez: I have a 2.26.9~ppa2 in edge on amd64, could you please double check that this fixes the issue you saw on trusty?
[12:58] <fgimenez> mvo: sure! on it
[12:59] <mvo> ta
[13:00] <mup> PR snapcraft#1398 closed: tests: fix issues with python 3.6 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1398>
[13:00] <mup> PR snapcraft#1401 closed: Correct capitalisation for PyPI <Created by evandandrea> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1401>
[13:03] <mup> PR snapcraft#1393 closed: python plugin: output json in pip list <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1393>
[13:03] <zyga> Chipaca: hey
[13:04] <zyga> Chipaca: standup time?
[13:04] <niemeyer> Chipaca: Oops.. wrong channel.. yeah, that ^
[13:04] <niemeyer> :)
[13:09] <mup> PR snapcraft#1375 closed: tests: allow to filter tests in docker <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1375>
[13:15] <mup> PR snapcraft#1383 closed: autotools: Enable cross-compilation support <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1383>
[13:21] <mup> PR snapcraft#1396 closed: rust plugin: unset http_proxy for test_cross_compile <Created by chihchun> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1396>
[13:22] <Son_Goku> cachio, mvo: travis/spread failures in https://github.com/snapcore/snapd/pull/3577
[13:22] <mup> PR snapd#3577: packaging/fedora, tests: Fix build for snapd and enable a test for Fedora <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3577>
[13:22] <Son_Goku> not sure what happened
[13:25] <cachio> Son_Goku, there are some errors to build fedora, I fix them in https://github.com/snapcore/snapd/pull/3505
[13:25] <mup> PR snapd#3505: PLEASE IGNORE: Enabling main test suite for fedora <Created by morphis> <https://github.com/snapcore/snapd/pull/3505>
[13:25] <Son_Goku> ah
[13:26] <Son_Goku> cachio, so then that means the fedora test shouldn't be enabled yet anyway
[13:27] <cachio> Son_Goku, trying to enable fedora tests for main test suite
[13:28] <mup> PR snapd#3051 closed: interfaces: add consoles interface <Blocked> <Decaying> <Created by femdom> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/3051>
[13:32] <cachio> Son_Goku, you can fix that error by changing in the file tests/lib/prepare-project.sh as I did in that PR
[13:34] <jdstrand> mvo: hey, looking at https://github.com/snapcore/snapd/pull/3579 you've decided to just use what is in the archive instead of embedded the upstream source? (I read the forum posts but wasn't sure)
[13:34] <mup> PR snapd#3579: snap-seccomp: link libseccomp statically to snap-seccomp <Created by mvo5> <https://github.com/snapcore/snapd/pull/3579>
[13:39] <Son_Goku> cachio: https://github.com/snapcore/snapd/pull/3577
[13:39] <mup> PR snapd#3577: packaging/fedora, tests: Fix build for snapd and enable a test for Fedora <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3577>
[13:40] <Son_Goku> I added your commit
[13:41] <mvo> jdstrand: I hit a bit of a roadblock with the embedding releated to tests, gustavo suggested some possible workarounds
[13:41] <cachio> Son_Goku, nice, I'll take a look to the results
[13:42] <jdstrand> mvo: yeah, that is what I read, but the new PR seems to just use archive packages, correct?
[13:42] <jdstrand> (which I happen to prefer in terms of security tracking)
[13:43] <mvo> jdstrand: correct
[13:43] <mvo> jdstrand: its as minimal as possible
[13:43] <mvo> jdstrand: exploring with fgimenez currently if it really fixes all the issues
[13:43] <jdstrand> mvo: ok, I wasn't sure another larger PR didn't sneak in-- it was so small :)
[13:44] <mvo> jdstrand: so because I hit this roadblock, I decided to try the static linking first to unblock us. I'm a bit worried about timing mostly, I want to release. and I think the static linking is not a bad solution, we can still do the full embedding later (once the problem with the tests is better understood)
[13:46] <jdstrand> mvo: I commented with +1. Like I said, I personally prefer this PR's approach with my Ubuntu security team hat on, so if you never circle back around, I'm still happy ;)
[13:47] <Son_Goku> mvo, I don't particularly prefer to statically link if I don't have to
[13:47] <Son_Goku> can we make this an ubuntu-only special somehow?
[13:48] <Chipaca> zyga: niemeyer: oops, sorry for not letting you know: i had an annual echp review meeting at standup time
[13:48] <zyga> Chipaca: echp?
[13:48] <Chipaca> zyga: ehcp, typo
[13:48] <zyga> ehcp? :D
[13:48] <Chipaca> zyga: boys' school stuff
[13:49] <zyga> ah :)
[13:49] <zyga> such a fancy name
[13:49] <Chipaca> zyga: “education, health and care plan”
[13:50] <Chipaca> i've got two of those every year, and a couple of "mini" ones every four months
[13:50] <zyga> embedded hampster cthulu party
[13:50] <Chipaca> JamieBennett: but the good news is, the other ones i thought were actually this month are in august instead \o/
[13:52] <Chipaca> Son_Goku: are the followup commits on snapd#3577 because it failed to actually work once it started actually trying to run tests?
[13:52] <mup> PR snapd#3577: packaging/fedora, tests: Fix build for snapd and enable a test for Fedora <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3577>
[13:52] <Son_Goku> Chipaca: yes
[13:52] <Chipaca> Son_Goku: sorry if this sounds uppity, but i'm glad i asked for that then :-D
[13:52] <Son_Goku> cachio pointed them out to me
[13:53]  * Son_Goku should also make a script to generate fancy from-git changelogs like the ones mvo does for debian packaging
[13:53] <zyga> Son_Goku: woot, thanks!
[13:53] <Son_Goku> zyga: this doesn't fix everything, as there's still problems with the test suite
[13:53] <Son_Goku> and spread is still being flakey
[13:54] <zyga> Son_Goku: but it moves a lot towards where it should be
[13:54]  * Son_Goku shrugs
[13:54] <Son_Goku> it was mentioned at the sprint that the spec wasn't working with git master
[13:54] <zyga> Son_Goku: I wanted to sync with downstream packaging but I wasted 15 hours on raspberry PIs and other SBC and my modem connection
[13:55] <Son_Goku> and no one wanted to actually fix it, so I just pulled my pending changes and pushed them
[13:55] <zyga> Son_Goku: now I even have my desk assembled, soon will be back to operational status
[13:55] <zyga> Son_Goku: I love how you improved the packaging btw :
[13:55] <zyga> :)
[13:55] <Son_Goku> well, I was horrified by the mvo5 fork of seccomp-golang
[13:55] <Son_Goku> then I looked at the fork and was like, "nah, I don't care"
[13:55] <Son_Goku> so I forced it back to mainline
[13:56] <Son_Goku> the benefits of not using vendored go deps :)
[14:00] <zyga> Son_Goku: I just send some review your way
[14:00] <zyga> Son_Goku: I think the quoting is off
[14:01] <Son_Goku> I ripped it from the original commit in a different PR
[14:01] <Son_Goku> if it's wrong, I'll clean it up
[14:02] <zyga> Son_Goku: I think it's wrong
[14:02] <zyga> Son_Goku: try it out
[14:03] <Son_Goku> yeah, I think it's wrong
[14:05] <Son_Goku> zyga: done
[14:11] <zyga> Son_Goku: approved
[14:11] <Son_Goku> now we wait for spread to fail
[14:11]  * zyga moves modem contraption to the attic, offline for 5 minutes
[14:12] <Son_Goku> :)
[14:25] <Saviq> kalikiana_, hey, does this ring a bell http://pastebin.ubuntu.com/25068497/? same happens with container builds... the part is just nil plugin with some stage-packages...
[14:33] <mup> PR snapcraft#1402 closed: Better explain dependency link processing <Created by evandandrea> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1402>
[14:35] <fgimenez> mvo: after adding the reboot all works fine with 2.26.9 on 14.04 http://paste.ubuntu.com/25068518/ \o/
[14:36] <zyga> :-)
[14:36] <fgimenez> mvo: i've tried with reexec both disabled (the default for the sru validation) and enabled, in this case only a few tests, the prepare step which was failing passes now
[14:52] <jdstrand> sergiusens, tyhicks: thanks to davidcalle, https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/. This is a redirect to the new location at https://developer.ubuntu.com/core/documentation
[14:53] <tyhicks> very nice
[15:01] <cachio> Son_Goku, you got another error about permission denied to install packages
[15:02] <coreycb> jdstrand: should the openstack auto-aliases should be enabled automatically at this point at install time? i'm on xenial with snapd 2.26.8.
[15:02] <cachio> Son_Goku, apply the change in tests/lib/pkgdb.sh from my P
[15:02] <cachio> R
[15:02] <cachio> Son_Goku, it is to fix that problem
[15:02] <coreycb> jdstrand: they don't appear to be, at least for keystone.  but first time using auto-aliases so could be a user error.
[15:02] <Son_Goku> zyga told me to remove it :P
[15:02] <Son_Goku> I'll add it back in a bit
[15:02] <Son_Goku> about to drive
[15:03] <cachio> Son_Goku, I am gonna lunch, I'll be back in 20 minuteas
=== cachio is now known as cachio_lunch
[15:05] <mvo> fgimenez: nice, so all tests looking good so far? great to hear
[15:06] <fgimenez> mvo: yep, to be extra sure i've triggered the full suite with reexec enabled and is good so far 121/175
[15:08] <mvo> fgimenez: much appreciate your care on this, thank you
[15:09] <fgimenez> mvo: np, thank you for finding the solution!
[15:09] <jdstrand> coreycb: they should be in effect. let me check something
[15:09] <niemeyer> Lunch, biab
[15:17] <pstolowski> fgimenez, hey, I think you addressed the comments to #3489? if so I'm going to merge it
[15:18] <fgimenez> pstolowski: hey, let me check
[15:19] <fgimenez> pstolowski: indeed, the changes mentioned in the review were mistakingly done in spread.yaml, all fixed now
[15:20] <pstolowski> fgimenez, thanks
[15:20] <fgimenez> pstolowski: np thank you
[15:20] <mup> PR snapd#3489 closed: tests: add bluetooth-control interface test <Created by fgimenez> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3489>
[15:22] <jdstrand> coreycb: there is a bug in the store that led me to enter the wrong snap declaration
[15:22] <coreycb> jdstrand: ah, ok
[15:22] <jdstrand> coreycb: I'll followup with the store team
[15:23] <coreycb> jdstrand: sounds good, thanks
=== JanC is now known as Guest50617
=== JanC_ is now known as JanC
[15:27] <jdstrand> coreycb: actually, strike that. it was only the snap declaration that was wrong. keystone should be fixed now
[15:27] <coreycb> jdstrand: cool i'll give it a shot
[15:28] <Saviq> sergiusens, hey, does this ring a bell http://pastebin.ubuntu.com/25068497/? same happens with container builds... the part is just nil plugin with some stage-packages...
[15:32] <sergiusens> no it really doesn't ring any bell. I can try that here... it only fails on containers? if it is a cleanbuild, add `--debug` at the end and you should get a shell
[15:36] <jdstrand> coreycb: I just fixed glance, neutron and nova. nova-hypervisor was not affected. verified locally with snap install and 'snap aliases'
[15:36] <jdstrand> coreycb: sorry for the hiccup
[15:38] <coreycb> jdstrand: np!  it's looking better.  going for a full deploy now. if you don't hear back from me i'm all good.
=== cachio_lunch is now known as cachio
[16:12] <fgimenez> i'm EOD'ing now, see you tomorrow o/
[16:49] <untoreh> can I disable seccomp in snapd ?
[16:50] <Chipaca> untoreh: tell me more
[16:51] <untoreh> I am trying to run anbox and dmesg is dumping audit with sig=31 so I want to disable seccomp, anbox is using bpf
[16:55] <mup> PR snapd#3580 opened: store: configurable base api <Created by atomatt> <https://github.com/snapcore/snapd/pull/3580>
[16:58] <Chipaca> untoreh: anbox is only available as a devmode snap
[16:58] <Chipaca> untoreh: so the seccomp things are warnings only
[16:58] <Chipaca> untoreh: (if they weren't, your application would've been terminated)
[17:12] <zyga> Chipaca: 31 is SIGSYS
[17:13] <zyga> Chipaca: seccomp doesn't have advisory mode
[17:13] <Chipaca> zyga: oh, i thought it did? bah :-(
[17:13] <ogra_> Chipaca, anboox is a classic snap ...
[17:13] <Chipaca> nope
[17:13] <ogra_> well, the installer at least
[17:13] <Chipaca>   beta:      1-dev     (15) 357MB devmode
[17:13] <Chipaca>   edge:      3-7fc8bb4 (37) 357MB devmode
[17:16] <Chipaca> zyga: i thought it had advisory mode, but not return-error-instead-of-dying mode
[17:17] <Chipaca> shows how much i know about that side of things =)
[17:17] <zyga> Chipaca: nope, it has kill or do nothing modes today
[17:17] <zyga> where nothing includes not logging
[17:17] <Chipaca> then i don't know how untoreh is seeing what they're seeing
[17:18] <Chipaca> maybe they're installing it with --jailmode ?
[17:18] <Chipaca> anyhow, eod for me
[17:18] <Chipaca> cuppa tea and guitar
[17:18] <Chipaca> o/
[17:30] <mup> PR snapd#3505 closed: PLEASE IGNORE: Enabling main test suite for fedora <Created by morphis> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3505>
[17:33] <untoreh> the installer is classic, andbox is dev
[17:34] <untoreh> the bpf profiles are @complain
[17:35] <zyga> untoreh: that is equal to no-op for now
[18:48]  * zyga_ got routing metrics reversed
[18:48] <zyga_> now things actually should behave /o\
[18:48] <zyga_> why isn't home network not just "snap install smart-home-router"
=== zyga_ is now known as zyga
[19:36] <cachio> niemeyer, about the PR 3505 that you recently closed, I have all the test cases fixed for fedora
[19:36] <cachio> it is ok if I reopen this
[19:37] <cachio> this PR has some overlap with the 3577
[19:37] <cachio> the idea is, once the 3577 is merged, then I'll remove the code to fix the building from the 3505 and then I'll propose it for reviewing
[19:55] <mup> PR snapd#3505 opened: PLEASE IGNORE: Enabling main test suite for fedora <Created by morphis> <https://github.com/snapcore/snapd/pull/3505>