[04:19] <miken> I've just pulled the snappy-examples and built the hello-world, but get a bunch of errors and warnings about files which don't exist: http://paste.ubuntu.com/11488439/ Is that expected, or related to my env?
[04:20] <miken> (it does build the snap, but unsure why I see those errors/warnings)
[07:28] <dholbach> good morning
[07:40] <fgimenez> hi mvo, i'm trying the examples at https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-examples
[07:40] <mvo> hey fgimenez, good morning
[07:41] <fgimenez> mvo, morning :)
[07:41] <fgimenez> mvo, on rolling/edge i'm getting the same aa_change_on_exec error you just reported for every snap
[07:42] <mvo> fgimenez: yeah, please use 15.04/edge for now, the rolling images are literally only ~30min old :) I enabled wily this morning on them and this was the first bug I noticed
[07:42] <mvo> fgimenez: I have not investigated further but it appears the apparmor profiles are not created
[07:42] <fgimenez> mvo, ok thx :) on 15.04/stable i'm getting this http://paste.ubuntu.com/11491522/ when trying to use the config hook, have you seen that before?
[07:43] <fgimenez> mvo, in the config-example snap
[07:44] <fgimenez> mvo, didn't try 15.04/edge though, doing it now
[07:44] <mvo> fgimenez: does the directory /var/lib/apps/config-example/1.0.6  exist?
[07:44] <mvo> fgimenez: it does not ring a bell, I will have to install/test in a VM to debug further
[07:45] <fgimenez> mvo, no, the one that exists includes the origin /var/lib/apps/config-example.sideload/1.0.6
[07:52] <dholbach> mvo, ogra_, asac: http://ubucon.de/2015 :)
[07:52] <mvo> woah, berlin
[07:55] <dholbach> the cfp has started and they'd be happy if we could talk about all the new stuff we're doing and maybe do a workshop or two
[07:57] <mvo> fgimenez: aha, thanks. thats the bug then, the .sideload is not taken into account :/
[07:57] <mvo> fgimenez: would you mind to file a short bug (this irc log is enough) so that its not forgoten?
[07:57] <mvo> fgimenez: should be easy to fix :)
[07:57] <fgimenez> mvo, of course thx :)
[08:08] <elopio> good morning.
[08:25] <davidcalle> Morning all
[08:33] <beowulf> morning
[09:04] <D_Cent> hi - i have trouble connecting to wi-fi with snappy ubuntu on a raspi2. i followed the wifi tutorial and installed the wireless-tools, etc. but if i connect the wifi dongle via usb, dmesg only shows that a new device was connected without loading any drivers or firmware. the interface wlan0 or similar also doesn't exist. how can i make it work? i had it running previously on an older image, so it should be working
[09:06] <JamesTait> Good morning all; happy Monday, and happy Say Something Nice Day! 😃
[10:43] <ogra_> mvo, beuno, hulp ! ... can one of you let chatroom through ? seems the review tools seem to be messed up ("ports is pbsolete in package.yaml")
[10:43] <ogra_> *obsolete
[10:52] <beowulf> ogra_: do you need this asap?
[10:52] <ogra_> beowulf, mectors does i think ... i'm just trying an upload with changed ports directive though
[11:07] <ogra_> mvo, could you take a look at https://myapps.developer.ubuntu.com/dev/click-apps/1526/ ?
[11:08] <ogra_> i dont get why it spits out the two warnings (my snap overview page tells me 0.1-8 is published btw ... only the details page tells me it isnt)
[11:18] <zyga> can I freely change the hostname of a snappy core system?
[11:36] <beuno> om26er, on it
[11:36] <beuno> er
[11:36] <beuno> ogra, on it
[11:36] <beuno> (who is not in the channel :))
[12:06] <mvo> ogra_: hi, you can ignore those warnings for now, we need to stop generating those .snappy-systemd files, they are no longer needed
[12:06] <beuno> ogra_, I approved it
[12:07] <beuno> the fix is on the store side
[12:07] <beuno> I have it pending
[12:07] <ogra_> beuno, ok, thanks ... if now the snap would actually work :/
[12:07] <ogra_> beuno, btw, where do i file store bugs ?
[12:08] <beuno> ogra_, https://bugs.launchpad.net/software-center-agent/
[12:08]  * ogra_ has 5 pairs of identical mails for the last uploads ... no mention which version which mail belongs to 
[12:09] <ogra_> and my front apps page said the whoile time that 0.1-8 was accepted
[12:09]  * beuno nods
[12:10] <ogra_> now why the heck does the chatroom not work anymore :/
[12:23] <sergiusens> ogra_: maybe seccomp
[12:23] <ogra_> sergiusens, hmm, i dont see any special messages about syscalls
[12:24] <ogra_> what i see is:
[12:24] <ogra_> Jun  1 12:23:01 localhost kernel: [ 2188.201850] audit: type=1400 audit(1433161381.662:146): apparmor="DENIED" operation="open" profile="chatroom.sideload_chatroom_0.1-8" name="/" pid=2356 comm="nodejs" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[12:24] <ogra_> but that has always been there
[12:24]  * ogra_ has an old install around that works fine on an old snappy 
[12:24] <sergiusens> ogra_: why would you want to read / anyways ;-)
[12:24] <ogra_> node does for whatever reason
[12:24] <sergiusens> ogra_: amd64 or armhf, I can try and install to see
[12:25] <ogra_> but that never did any harm
[12:25] <ogra_> this is currently amd64
[12:25] <ogra_> in kvm
[12:25] <Chipaca> mvo: any luck reproducing the issue wrt install not working?
[12:25] <ogra_> my RPi is using a messed up image because i try to fix it :P
[12:26]  * ogra_ tries an older node-snapper tarball 
[12:29] <mvo> Chipaca: no, but I didn't try further, sorry, I will try again in a little bit
[12:30] <sergiusens> ogra_: the one on the store works fine on 1.8
[12:30] <sergiusens> ogra_: err
[12:30] <Chipaca> sergiusens: does 'snappy install' work for you in a vm?
[12:30] <sergiusens> ogra_: the one on the store, 1.8, works fine on bbb
[12:30] <ogra_> ARGH !!!
[12:31] <ogra_> sergiusens, because i'm the super idiot today
[12:31]  * ogra_ tested with firefox :P
[12:31] <sergiusens> ogra_: no binary for amd64?
[12:31] <ogra_> (only works with chromium)
[12:31] <ogra_> sure, it is multi arch
[12:32] <sergiusens> ogra_: ah, I tried on chrome fwiw
[12:32] <ogra_> yeah, man, i wasted 2h on that :/
[12:34]  * ogra_ adds that info to readme.md for next time :P
[12:36]  * ogra_ takes a break, phew ... 
[12:39]  * Chipaca realises he hasn't updated in ages
[12:45] <rsalveti> hm, our builders are in a funny state
[12:48] <ogra_> rsalveti, which ones ? images ?
[12:48] <rsalveti> normal lp builders
[12:48] <rsalveti> some are busy with the haskell uploads
[12:48] <rsalveti> but at our ppa all I get is 'start on'
[12:48] <rsalveti> no estimation at all
[12:50] <ogra_> hmm
[12:50] <rsalveti> like https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/7492026
[12:51] <rsalveti> mvo: hm, ubuntu-snappy is also ftbfs on i386 for vivid
[12:51] <rsalveti> https://launchpadlibrarian.net/207810741/buildlog_ubuntu-vivid-i386.ubuntu-snappy_1.0.1-1%2B443~ubuntu15.04.1_BUILDING.txt.gz
[12:51] <ogra_> yeah, i just saw the mail
[12:51] <mvo> rsalveti: I noticed but couldn't make sense of the failure yet
[12:52] <ogra_> rsalveti, for the hanging build we should poke cjwatson i think
[12:52] <ogra_> oh, thats a different error ...
[12:52]  * ogra_ had some with dependency issues on the weekend
[12:52] <rsalveti> ogra_: yeah, let's wait a bit more and ping him if still stuck
[12:52] <ogra_> yup
[12:53] <rsalveti> yeah, why TestUpdateTimestamp would fail
[12:54] <rsalveti> wonder if a rebuild will make any difference
[12:55] <ogra_> 2015-05-30 02:46:51 ERROR snappy logger.go:199 hello-app.potato failed to install: a package by that name is already installed
[12:55] <ogra_> what about that one ?
[12:55] <rsalveti> wonder if that is testing the error itself
[12:55] <ogra_> does it re-run the test in a loop or some such ?
[12:55] <rsalveti> since the test passed
[12:55] <ogra_> ah
[12:56] <rsalveti> just a guess, didn't yet see the code :-)
[12:56] <rsalveti> let me open a bug for this guy
[12:56]  * ogra_ sighs ... i upgraded my laptop to vivid on the weekend ... got close to unusable now :(((
[12:57] <ogra_> constantly to hot (80-90°C)
[13:01] <rsalveti> https://bugs.launchpad.net/snappy/+bug/1460650
[13:01] <rsalveti> ogra_: any process in particular eating your cpu?
[13:01] <rsalveti> maybe new browsers
[13:01] <ogra_> no, not at all
[13:02] <rsalveti> vivid is mostly fine for me
[13:02] <ogra_> but starting chromium with no page open bumps the load to 12.00 ... while chromium only takes ~20% of one of the cpu cores (the rest is idle)
[13:02] <ogra_> the frequesncy scaling seems pretty messed up
[13:10] <mterry> mvo, you should open up ownership of lp.net/ubuntu-core-launcher
[13:10] <mterry> Wanted to configure its bug tracker to show its bugs (right now I can't see bugs assigned to it because it's not set up)
[13:10] <sergiusens> nessita: what's the difference between price and prices, if the answer is, 'price' is legacy it's a good answer already :-)
[13:11] <Chipaca> so
[13:11] <Chipaca> on my system
[13:11] <sergiusens> mterry: I just ubuntu bug'ed it
[13:11] <Chipaca> snappy is bailing because it can't read /etc/localtime?
[13:11] <Chipaca> ah, no, it's before that
[13:11] <Chipaca> rats
[13:11] <nessita> sergiusens, correct! (price is legacy and is the price for the default currency(
[13:11]  * Chipaca carries on
[13:11] <nessita> __
[13:11] <nessita> ))
[13:11] <mterry> sergiusens, you did...?
[13:12] <rsalveti> mvo: mterry: just put ubuntu-core-launcher under https://launchpad.net/~snappy-dev
[13:12] <mvo> rsalveti: excellent, thanks
[13:13] <Chipaca> i don't understand this failure :(
[13:17] <ogra_> BAH ... i seem to have half a mobile desktop installed ... no wonder that laptop misbehaves !
[13:21] <rsalveti> mvo: oh, sorry, I wanted to say that you could put it under ~snappy-dev :-)
[13:21] <rsalveti> only you can change it
[13:23] <sergiusens> nessita: I did.... nothing?
[13:23] <mvo> rsalveti: ups, sure
[13:23] <sergiusens> Chipaca: what's the issue?
[13:23] <sergiusens> Chipaca: btw, can you review my u-d-f change?
[13:23] <Chipaca> sergiusens: snappy internal unpack dies with "operation not supported"
[13:24] <Chipaca> and the strace shows no syscall failure
[13:24] <sergiusens> Chipaca: amd64 or bbb?
[13:24] <Chipaca> sergiusens: mad64
[13:24] <mvo> rsalveti: updated, the project is now owned by ~snappy-dev
[13:24] <nessita> sergiusens, you meant mterry?
[13:24] <rsalveti> mvo: cool, thanks (mterry ^)
[13:25] <sergiusens> nessita: I did!
[13:25] <mterry> mvo, thanks!  :)
[13:25] <sergiusens> mterry: ubuntu-bug ubuntu-core-launcher
[13:25] <rsalveti> but that will use the package bug
[13:26] <sergiusens> rsalveti: yes
[13:28] <Chipaca> the setuid/setgid fails
[13:29] <Chipaca> the setgid, in particular
[13:29] <Chipaca> can i say WAT?
[13:29] <mvo> Chipaca: uh, hope its not something silly as setuid and then setgid :/ in this particular revision
[13:29] <mvo> (i.e. order wrog)
[13:29] <Chipaca> no, it does setgid and then setuid
[13:29] <mvo> wrong even
[13:29] <mvo> ok
[13:30] <Chipaca> and the setgid fails
[13:30] <Chipaca> this is beyond weird, because the snappy we ship works
[13:31] <mterry> mvo, I also see that someone subscribed snappy-dev to snappy bugs.  Maybe snapcraft and ubuntu-core-launcher should get the same treatment?
[13:33] <sergiusens> Chipaca: hmm, I face this problem when locally building snappy (I think)
[13:34] <rsalveti> mterry: I did that, yup, makes sense
[13:34] <mterry> rsalveti, thanks!
[13:35]  * Chipaca files bug #1460658
[13:35] <Chipaca> sergiusens: and how did you fix it?
[13:41] <sergiusens> Chipaca: I haven't, sorry
[13:50]  * Chipaca -> school run
[14:08] <sergiusens> nessita: can I use the 'id' for a package to get results for it?
[14:09] <sergiusens> nessita: as in using 2277 (id) instead of https://search.apps.ubuntu.com/api/v1/package/beagleblack
[14:13] <nessita> sergiusens, nopes, ID is retured by mistake,never rely on that
[14:27] <mvo> jdstrand: do you know why livecd-rootfs uses the "-M /var/cache/apparmor/.features" flag in ubuntu-touch? this file is not available in our chroot it seems
[14:30] <sergiusens> nessita: so the resource name is always the package_name.origin or alias, correct?
[14:30] <jdstrand> mvo: what is -M an argument to?
[14:30] <mvo> jdstrand: apparmor_parser -M (--features-file) I think
[14:31] <mvo> jdstrand: I'm not sure why its there for touch when they pre-build the /etc/apparmor.d/cache
[14:32] <jdstrand> ah, that is not in the manpage it seems
[14:32] <mvo> yes, I only found it with apparmor_parser -h and have no idea what its doing
[14:33] <jdstrand> mvo: iirc, if you specify a different --cache-loc (-L), then you need to have a .features file in it
[14:33] <mvo> ok
[14:34] <jdstrand> since there is /etc/apparmor.d/cache for system and /var/cache/apparmor for apps, we have a .features file in both
[14:34] <ogra_> echo "I: precompiling click apparmor policies"
[14:34] <ogra_> /sbin/apparmor_parser -M ${FEATURES} -Q --write-cache --cache-loc=/var/cache/apparmor/ `find /var/lib/apparmor/profiles/ -maxdepth 1 -type f -not -path '*/\.*'`
[14:34] <ogra_> (thats from the code)
[14:34] <ogra_> looking in the last image build log it seems to run fine without complaints
[14:34] <ogra_> (touoch that is)
[14:35] <jdstrand> perhaps it is putting a .features file in place so that the compiler will use it instead of querying the kernel?
[14:35] <ogra_> https://launchpadlibrarian.net/207811375/buildlog_ubuntu_wily_armhf_ubuntu-touch_BUILDING.txt.gz
[14:35] <ogra_> i wouldnt know what would put that file there
[14:35] <jdstrand> I think rsalveti and/or jjohansen would know
[14:36] <jdstrand> I know that a .features file is put in place on the running system in each cache directory
[14:36] <jdstrand> the running non-livecd system that is
[14:36] <mterry> tedg, we should try to define a minimal set of snapcraft bits that we think we can move forward with this week
[14:37] <ogra_> jdstrand, what puts it there ? the upstart job ?
[14:37] <jdstrand> and I know you can specify a different features file to adjust cache output
[14:37] <jdstrand> so you could compile caches for another kernel
[14:38] <ogra_> there is definitely no code in livecd-rootfs putting that file in place
[14:38] <ogra_> and i doubt it actually exists in the chroot after bootstrapping
[14:39] <nessita> sergiusens, yes
[14:42] <jdstrand> I'm not sure. I think the parser might
[14:42] <tedg> mterry, Yes, I haven't looked at the current code. I would like to get some stuff starting to work-ish
[14:42] <tedg> mterry, I think we can do that even if all the spec parts aren't perfected.
[14:43] <jdstrand> yes
[14:43] <jdstrand> If cache/.features is missing, create it if --write-cache
[14:44] <mterry> tedg, current code is an empty branch
[14:45] <jdstrand> I'm still going to defer to jjohansen
[14:45] <ogra_> that makes it at least bugfree
[14:45] <tedg> mterry, tabula rasa
[14:45] <ogra_> jdstrand, well, it doesnt seem to do any harm
[14:45] <ogra_> (not sure what mvo's prob is with it)
[14:51] <Chipaca> sergiusens: mvo: it fails when compiled with golang 1.4 (!)
[14:52] <Chipaca> mvo: does this match the failures you were seeing in arm64?
[14:52] <Chipaca> or gogcc
[14:53] <Chipaca> maybe i just need to rebuild my go 1.4
[14:53] <Chipaca> or switch to wily already
[14:53] <mvo> Chipaca: ohhhh, I have not tried that
[14:53] <mvo> Chipaca: in a meeting right now :/ so can't help just yet
[14:53] <Chipaca> mvo: is this the "15.04.1 release" meeting?
[14:54] <mvo> Chipaca: yes, I almost missed it fighting with gccgo
[15:00] <sergiusens> Chipaca: right, I'm using 1.4 here (locally installed)
[15:01] <Chipaca> sergiusens: vivid's 1.3 worked
[15:02] <Chipaca> sergiusens: locally installed 1.3 also works
[15:25] <Chipaca> I guess I won't be running snappy on my http://wiki.openwrt.org/toh/kingston/mlw221 any time soon
[15:27] <mvo> 16mb flash is going to be hard
[15:28] <ogra_> pfft
[15:29] <ogra_> just write a proper compression that allows pushing 4G into 16M ...
[15:30] <mvo> 4gb of /dev/zero surely
[15:33] <Chipaca> mvo: so, the manifest branch is the one causing the apparmor failures
[15:44] <mvo> Chipaca: the reduce-manifest one?
[15:44] <Chipaca> mvo: yaarp
[15:44] <mvo> ok
[15:46] <elopio> fgimenez: tomorrow I can escape at 11:30, london time.
[15:46] <Chipaca> mvo: still trying to understand why, but i'll get there :)
[15:46] <tedg> Where are the package lists for the default core image?
[15:46] <tedg> seed I guess?
[15:47] <tedg> Is it this? https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-core.wily
[15:51] <fgimenez> elopio, fine, that is 10:30 my time. i'm already taking a look at the doc
[15:51] <fgimenez> elopio, ping me when you are ready
[15:53] <jdstrand> mvo, Chipaca: if I were to hazard a guess, I would think it has something to do with the 'namespace' changes in click.go
[15:54] <Chipaca> jdstrand: nope :)
[15:54] <jdstrand> oh, what is it?
[15:57] <elopio> fgimenez: great, thanks.
[16:00] <Chipaca> jdstrand: in revision 465 i switched some bits to use the yaml manifest instead of the click manifest
[16:01] <Chipaca> jdstrand: without noticing that things that appeared equal were not so
[16:02] <Chipaca> in my defence, in build we assign the click manifest's Hooks to be the yaml's Integration
[16:03] <Chipaca> but before doing that we do add some things to Integration that are not in the package.yaml
[16:04] <Chipaca> so, I *think* what we want is to grow Integration in the same way every time we load it
[16:05] <Chipaca> I need to check though :)
[16:17] <jdstrand> mvo: fyi, and this doesn't have anything to do with snappy internals, I have adjust the review tools to error if a snap uses 'integration' in its yaml
[16:17] <jdstrand> adjusted*
[16:58] <jdstrand> sergiusens: hey, I'm reflashing my bbb, is udf 0.21-1+174~ubuntu15.04.1 ok to use?
[17:09] <sergiusens> jdstrand: let me check
[17:11] <sergiusens> jdstrand: yes
[17:18] <tedg> So, I thought I'd go to the docs, didn't find my answer there either :-)
[17:18] <tedg> Where is the script/tool/etc that builds the core snap?
[17:19] <jdstrand> sergiusens: thanks
[17:19] <jdstrand> df
[17:19] <tedg> 1243 GB
[17:20] <ogra_> 640k are enough for everyone !
[17:20] <jdstrand> heh
[17:31]  * ogra_ upgrades ubuntu-device-flash
[17:31]  * jdstrand hrms
[17:33] <jdstrand> rsalveti, mvo: hello-dbus-app is broken on edge r72. is this the candidate for promotion?
[17:33] <jdstrand> rsalveti, mvo: (on bbb)
[17:46] <damjan> what would it take to port UbuntuCore to the Kindle Paperwhite
[17:49] <ogra_> damjan, depends what bootloader it uses ... if the specs would work etc
[17:50] <damjan> hardware specs?
[17:50] <ogra_> yes
[17:51] <ogra_> you need 4G diskspace and the ability to partition it the right way... we currently only support u-boot on arm as bootloader ...
[17:53] <damjan> it's an 1Ghz imx 508
[17:53] <damjan> 256MB ram
[17:53] <damjan> there's the 2GB and 4GB flash versions
[17:53] <ogra_> that might eb a little low on ram ... but givenn that there is no UI support in any way yet, perhaps not
[17:54] <ogra_> (i guess for plain cmdline 256M would work)
[17:56] <damjan> afaik it's u-boot
[17:56] <damjan> why does it matter btw?
[17:57] <ogra_> because the automation for rollbacks lives in the bootloader
[17:57] <ogra_> (if you upgrade and something goes wrong the system automatically rolls back to the last working setup)
[18:00] <damjan> it's uboot
[18:43] <jdstrand> rsalveti, mvo: fyi, there is a trello card to add hello-dbus-* to the self tests. if is in 'snappy core stackholders backlog' 'incoming propposals'. I just now added instructions on what to do (should be a very simple test)
[18:43] <jdstrand> rsalveti, mvo: s/if is/it is/
[19:34] <rroy> Trying to do basic install of docker app on snappy.    Installation completes w/o error however a simple `docker ps` fails:
[19:34] <rroy> ubuntu@localhost:~$ sudo snappy install docker Installing docker Starting download of docker.canonical 8.36 MB / 8.36 MB [[19:34] <rroy> Ugh ... sorry about the formatting.
[19:36] <rroy> As you can see the complaint is regarding a missing "profile" file.    I'm guessing I can get away w/ an empty profile file but ... what is the file name/location?
[19:50] <kgunn> seb128: you around ?
[19:51] <seb128> kgunn, yes
[19:56] <rsalveti> jdstrand: ogra_: we only have the features file for touch
[19:56] <rsalveti> ubuntu-touch/includes.chroot/var/cache/apparmor/.features
[19:57] <rsalveti> so I'd guess the pre-cached apparmor stuff is kind of useless for core atm
[19:58] <rsalveti> jdstrand: broken on 15.04/edge?
[20:00] <jjohansen> rsalveti: that does sound broken
[20:05] <jdstrand> rsalveti: yes, r72
[20:06] <jdstrand> rsalveti: I think it is surrounding the unshare in the launcher because I am getting a disconnected path apparmor denial
[20:07] <rsalveti> jdstrand: and thanks for updating the card, will move it around later today
[20:07] <jdstrand> but it is weird, because it is on run/
[20:07] <rsalveti> but iirc it was working a few days ago
[20:07] <jdstrand> rsalveti: cool, thanks
[20:07] <jdstrand> I wonder what landed
[20:07] <rsalveti> now don't remember if that was indeed stable or edge
[20:07] <jdstrand> do we have a clear way to see what has changed?
[20:08] <rsalveti> not an easy way, no, ogra_ was working on that
[20:08] <rsalveti> we only got the manifest, but from a few images
[20:08] <jdstrand> I just reflashed my bbb today with edge and got this denial: audit(1433179950.388:19): apparmor="DENIED" operation="connect" info="Failed name lookup - disconnected path" error=-13 profile="hello-dbus-app.canonical_client_1.0.1" name="run/dbus/system_bus_socket" pid=1215 comm="dbus_message.ar" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=0
[20:09] <jdstrand> notice 'name=run/...'
[20:09] <jdstrand> that should have a '/' in front of it
[20:09] <rsalveti> indeed
[20:09] <jdstrand> so, we knew we would need to adjust the apparmor template to use 'attach_disconnected'
[20:09] <jdstrand> and in fect, that is done in wily
[20:10] <jdstrand> fact*
[20:10] <jdstrand> but, I wasn't expecting this on 15.04, so I'm curious about the changes that went in
[20:14] <jdstrand> rsalveti: so, the launcher hasn't changed in vivid...
[20:15] <jdstrand> rsalveti: ah, 1.0.2~ppa1 is on the image
[20:16] <rsalveti> right
[20:16] <jdstrand> rsalveti: 'Set up a private mount namespace for /tmp'
[20:16] <jdstrand> so, this means we need a policy update
[20:16] <rsalveti> we use vivid + https://launchpad.net/~snappy-dev/+archive/ubuntu/image
[20:17] <jdstrand> yep, that is where I'm looking
[20:17]  * jdstrand sees the old unused libseccomp and deletes it
[20:18] <rsalveti> also noticed we're over the repo size limit in there
[20:18] <rsalveti> maybe because of gcc
[20:18] <jdstrand> oh yeah
[20:19] <jdstrand> rsalveti: so, at this point there is a choice, pull the launcher or have me do a policy update. I'm fine with doing an ubuntu-core-security update-- I can do it tomorrow. this was the other part of the sru I was talking about
[20:19] <jdstrand> rsalveti: but if we go that route, you should block the promotion on that
[20:20] <rsalveti> yeah
[20:20] <rsalveti> jdstrand: that same version is also available in wily (core-launcher)
[20:20] <rsalveti> so I guess we'd need a policy update for both
[20:20] <jdstrand> rsalveti: wily has 1.0.2
[20:21] <jdstrand> wily already has the policy update
[20:21] <rsalveti> got it
[20:21] <jdstrand> 15.10.1 has: "add attach_disconnected for default policy in preparation of new /tmp
[20:21] <jdstrand>       handling"
[20:22] <rsalveti> guess it'd be fine to get this in the ppa and then work on getting the official src in place
[20:22] <jdstrand> that is what I was thinking
[20:23] <rsalveti> cool
[20:23] <rsalveti> jdstrand: do we have a bug for this already?
[20:23] <rsalveti> just so I can put at the milestone
[20:24] <jdstrand> no
[20:24] <jdstrand> I'll file one
[20:24] <rsalveti> awesome, thanks
[20:26] <jdstrand> rsalveti: bug 1460810
[20:27] <rsalveti> jdstrand: thanks
[21:06] <jdstrand> rsalveti: fyi, ubuntu-core-security - 15.04.12~ppa1 uploaded to the ppa
[21:06] <rsalveti> jdstrand: awesome, thanks for that
[21:07] <jdstrand> np
[21:07] <rsalveti> got the extra ppa space just in time
[21:33]  * Chipaca looks at sys/unix/syscall_linux_arm64.go
[21:33]  * Chipaca goes to bed
[21:56] <nessita> sergiusens, so, I have this item to sync with you, about snappy oauth-signing every single request to the index. Any pointers who should I ping about this?
[22:20] <Chipaca> nessita: for snappy?
[22:28] <beowulf> Chipaca: is your snap removed from the store?
[22:28] <Chipaca> beowulf: unpublished
[22:28] <Chipaca> beowulf: should i republish?
[22:28] <Chipaca> people seemed to not like it being there
[22:28] <beowulf> Chipaca: no, it exposed some wonderful errors :)
[22:28] <Chipaca> hee hee :)
[22:29] <beowulf> Chipaca: so i was using it in webdm, then it was unpublished, then i tried to uninstall...
[22:29] <Chipaca> beowulf: webdm doesn't like things disappearing from the store?
[22:29] <beowulf> Chipaca: no sir
[22:29] <Chipaca> *shock*
[22:29] <beowulf> Chipaca: i'm wondering if the store should dissappear metadata, or should webdm handle it, or should i go to bed
[22:30] <beowulf> i think the latter
[22:30] <Chipaca> jdstrand: is https://01.org/intel-kgt relevant to us?
[22:30] <Chipaca> beowulf: the magic 8-ball says "go to bed already"
[23:56] <sergiusens> Chipaca: beowulf this is a similar error to the offline case; I need to fix it
[23:58] <sergiusens> nessita: how soon is that timeline? I think you want to sync with beuno first on the whole concept for ssl/tls