[06:42] <dholbach> good morning
[07:06] <fgimenez> good morning
[07:14] <elopio> hey fgimenez: I think I've tried it all to get this working: https://code.launchpad.net/~elopio/snappy/go-tests5/+merge/262418
[07:14] <elopio> no luck.
[07:14] <fgimenez> elopio, hey still around? np, i'll take a look
[07:22] <fgimenez> elopio, the first time i tried i was getting http://paste.ubuntu.com/11739031/ did you get something like that?
[07:31] <fgimenez> elopio, i'll merge your changes and we can work from there
[07:38] <elopio> fgimenez: yes, I can't sleep when I get stuck.
[07:38] <elopio> and yes, that's what I get when I try to sbuild.
[07:56] <fgimenez> elopio, nw, i'll give it another try, go and get some sleep! :)
[08:34] <JamesTait> Good morning all; happy Friday, and happy Sauntering Day! 😃
[08:42]  * Chipaca saunters off to get coffee
[08:57] <elopio> fgimenez: yes, I'm going to sleep now.
[08:57] <elopio> I got adt-run working on my beagle. The tests don't pass, but they run.
[09:03] <fgimenez> elopio, awesome!! thx a lot, we'll talk later
[09:30]  * Chipaca now in wily \o/
[09:30] <ogra_> crazy
[09:33] <mvo> Chipaca: yay!
[09:33] <mvo> Chipaca: its much more fun this way, isn't it :-D
[09:36] <Chipaca> well, awesome changed its configuration in incompatible ways (new lua, i guess), so that was fun
[09:36] <Chipaca> but at least it wasn't xmonad :)
[09:39] <Chipaca> ogra_: not at all crazy; if i didn't do this, how could i be condescending to people running old software?
[09:39] <Chipaca> in bad faith, that's how
[09:39] <ogra_> lol
[09:40] <zyga> hmm
[09:40] <zyga> so how does snappy work
[09:40] <zyga> how do you build the os snap
[09:40] <zyga> is it based on debootstrap
[09:40] <zyga> followed by rm -rf /var/lib/dpkg
[09:40] <zyga> or is it something entirely different
[09:41] <ogra_> live-build builds it
[09:41] <zyga> I'm trying to understand if contributions to ubuntu archive have an impact on spappy
[09:41] <ogra_> based on config and extra scripts that live in livecd-rootfs
[09:41] <zyga> ahh
[09:41] <zyga> offspring lives forever, it seems ;-)
[09:42] <zyga> is that stable or constantly evolving?
[09:42] <ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
[09:42] <zyga> like the scripts that do magic after the base packages are installed
[09:42] <ogra_> no, luckily it isnt offspring or anyhow related
[09:42] <ogra_> sadly though to make parts of it offspring compatible we had to re-write the whole infra around it in python ... since then it got really hard to maintain
[09:43]  * ogra_ is still grumpy about that after years ... makes life so much harder ... 
[09:43] <zyga> ogra_: is there a high-level description of what goes into the os snap?
[09:43]  * ogra_ shakes his fist at cody-sommerville in absence
[09:43] <zyga> ogra_: (what was it written in originally?)
[09:43] <zyga> ;D
[09:44]  * zyga still has that memory of cody 
[09:44] <zyga> driking only after you are 21 and all that ;-)
[09:44] <zyga> fun days
[09:44] <ogra_> yeah, he was nagfging about the re-write for two years or so ... then the rewrite itself took about 6 months ... and just as it was done he left !
[09:44] <zyga> ogra_: I'm trying to picture this against debootstrap
[09:45] <ogra_> live-build uses debootstrap
[09:45] <zyga> ogra_: to understand where my assumptions are wrong, etc,
[09:45] <ogra_> for the initial chroot ...
[09:45] <zyga> ogra_: is there any input to the whole process other then the packages?
[09:45] <ogra_> and then installs/removes and modifys packages as needed
[09:45] <zyga> "modifies"?
[09:45] <ogra_> yes, there are chroot hooks that get run
[09:46] <ogra_> sure
[09:46] <ogra_> (it doesnt modify anything for the deb based images indeed, only for stuff that doesnt use dpkg at the enduser)
[09:48] <zyga> ogra_: thanks
[09:48] <zyga> ogra_: so the os snap is a preinstalled chroot
[09:48] <zyga> ogra_: with some cherries on top
[09:50] <Chipaca> zyga: also keep in mind the split between os, kernel and device snap
[09:50] <Chipaca> so not the whole chroot
[09:51] <ogra_> zyga, apt-get source livecd-rootfs ... live-build/auto/build and live-build/auto/config have the generic build parts ... live-build/ubuntu-core/hooks has the extra scripts
[09:51] <mvo> for some value of "generic"
[09:51] <mvo> (SCNR)
[09:52]  * Chipaca always thinks of french trains when he reads SCNR
[09:53] <ogra_> zyga, and built in a special way (i think we use --buildd-minimal or some such for deboostrap, the apt policy doesnt install recommends and so on)
[09:55] <zyga> Chipaca: s/device/gadget/ right
[09:55] <Chipaca> zyga: yes indeed
[09:56] <zyga> right
[09:58]  * ogra_ wonders if bug 1466672 isnt actually a feature :)
[09:59] <ogra_> though i guess it should print some meaningful error message in the log
[09:59] <ogra_> "cant run network service with no network attached" or some such
[10:03] <zyga> ogra_: hmm, why should webm not start?
[10:03] <ogra_> zyga, it runs an avahi daemon ... what should that attach to with no network up ?
[10:21] <zyga> ogra_: nothing, but then the avahi daemon will attach to each network as it shows up
[10:22] <zyga> ogra_: one of the bad things about many linux gizmos is that they misbehave if you boot without network and plug network later
[10:34] <ogra_> yep
[11:41] <mvo> Chipaca: quick brainstorm - what additional meta/meta.yaml do we need that is not part of the package.yaml. I have "origin" (mvo, sideloaded) on my list right now, what else will we want to store here?
[11:45] <olli> snap masters, do we have some documentation how to "debug" in snappy... tools but also "strategies", i.e. how to check whether it's an app vs system issue etc
[11:47] <mvo> olli: unfortunately not, its complicated by the fact that we do not have snaps for many of the useful tools (like strace) :/ - do you have a specific example where you need debugging help? maybe that could be the start of such a doc :)
[11:48] <olli> mvo, mterry & kgunn were holding my hand when creating a qmlscene snap
[11:48] <olli> got issues loading a lib at runtime
[11:48] <olli> which is there, suppose the preloader doesn't catch it
[11:49] <mvo> olli: anything in the usual places (dmesg, syslog) - might be somethin with appamror/seccomp
[11:49] <olli> alrighty
[11:52] <olli> mvo, are there any existing pointers / docs how to deal with confinement issues, i.e. I see a apparmor denial, what's next?
[11:59] <mvo> olli: could you pastebinit
[11:59] <mvo> olli: maybe jdstrand has pointeres to the security wiki
[12:00] <ogra_> olli, syslog is your best bet
[12:00] <olli> ogra_, I see the issue, just don't know what to do with it ;)
[12:01] <olli> mvo,  http://paste.ubuntu.com/11739849/
[12:01] <ogra_> olli, you could indee dship things like strace and such in a special version of your snap ... i.e. $app-debug.snap ... so that you could have these tools apply to the startup wrappers
[12:01] <olli> that's the runtime err
[12:02] <olli> and that's dmesg | tail -n 10 http://paste.ubuntu.com/11739855/
[12:04] <ogra_> olli, well, your app should ship its own /usr/share/applications ... or wait until that setup can be provided by some framework
[12:04] <ogra_> (wrt the DENIED messages there)
[12:04] <olli> ogra_, don't even know what it's trying to access there
[12:04] <olli> what's the best strategy to figure out what it's trying to access so I can bundle that stuff?
[12:05] <ogra_> well, you likely want to look at the code of your app then :)
[12:05] <ogra_> it might just want to read the .desktop file
[12:05] <ogra_> (which usually live in that dir)
[12:07] <olli> you are suggesting I read all of Qt?
[12:07] <Chipaca> mvo: i'm afraid i didn't pay too much attention, but (or because) sergio did :)
[12:07] <ogra_> all of qmlscene code i guess
[12:08] <sergiusens> Chipaca: what did I do again?
[12:08] <Chipaca> should kvm be bringing up an eth0?
[12:08] <Chipaca> sergiusens: what additional meta/meta.yaml do we need that is not part of the package.yaml. I have "origin" (mvo, sideloaded) on my list right now, what else will we want to store here?
[12:08] <mvo> Chipaca: I had this problem with latest wily too, no eth0
[12:08] <Chipaca> sergiusens: ^^ that was mvo asking, earlier today
[12:08] <mvo> Chipaca: rollback to a previous version worked
[12:08] <sergiusens> Chipaca: part of meta/package.yaml?
[12:09] <mvo> Chipaca, sergiusens: maybe its not relevant anymore my question, I'm drafting the FHS
[12:09] <Chipaca> sergiusens: i think he's asking about _$version
[12:09]  * Chipaca translates
[12:09] <sergiusens> mvo: if Chipaca's idea flies wrt dynamic creation f manifest.yaml from store data we need...
[12:11] <sergiusens> Chipaca: mvo video and screenshot url (and maybe even the shots), release is rather important (to deal with upgrades), icon downloaded, binary_filesize (which is the download size), developer name, company name, website, price, publish date, download sha
[12:11] <sergiusens> mvo: Chipaca and reviews would be one of those on demand queries
[12:12] <sergiusens> download sha is of little sense if we explode the package and expose hashes.yaml
[12:12] <sergiusens> oh, and changelog
[12:13] <sergiusens> and one of the bigger things coming our way, the translations entry
[12:13] <mvo> sergiusens: indeed
[12:13]  * sergiusens feels he just made too much words to just say everything
[12:14] <sergiusens> mvo: Chipaca I think we will be putting this in _$versions initially and then move over to the dynamically created manifest.yaml
[12:15] <sergiusens> we can have a hangout to go over it and get the big picture
[12:15] <sergiusens> I just need to cut off 30' after standup today though and then I'll be back by your bed/beer o clock ;-)
[12:16] <Chipaca> who's working on translations? i'd like to add my 2¢ to that work
[12:16] <sergiusens> Chipaca: the store already has that option
[12:16] <Chipaca> on the client
[12:17] <Chipaca> i don't mind if the store loads all translations in memory
[12:17] <sergiusens> Chipaca: and then you get a translations entry in the json
[12:17] <Chipaca> because it's the store :)
[12:17] <sergiusens> Chipaca: no one is yet
[12:17] <sergiusens> Chipaca: there's only mvo's branches which I'll look at again now
[12:17] <seb128> sergiusens, mvo, hey, maybe you know, but how/when is the "cdimage build" to "channel image" conversion done? is that a cron job? or does it trigger when need cdimage build are done?
[12:17] <sergiusens> seb128: all of Ubuntu's infra is poll based :)
[12:17] <mvo> seb128: system-image.u.c is doing that, its a cron job that runs every 5min
[12:18] <sergiusens> that was a snarky smiley
[12:18] <mvo> seb128: but it can run for a long time
[12:18] <mvo> seb128: so the 5min is not accurate
[12:18] <mvo> Chipaca: what specifically do you have in mind? other than adding gettext ? how to requested the languages from the store?
[12:18] <seb128> mvo, it's like the publisher, 5 minutes if there are not previous job overunning right?
[12:18] <seb128> sergiusens, mvo, thanks
[12:18] <ogra_> seb128, see the crontab on nusakan
[12:18] <sergiusens> seb128: btw, I still get reboot loops with amd64 and i386 just stalls during boot
[12:19] <ogra_> seb128, last line ...
[12:19] <sergiusens> seb128: and the personal branch made it to trunk btw
[12:19] <seb128> ogra_, thanks
[12:19] <ogra_> (well, the crontab of the cdimage user that is)
[12:19] <seb128> sergiusens, \o/ for personal to trunk
[12:19] <Chipaca> mvo: translations of snappy itself i'm less worried about; gettext already uses one-file-per-language and is (or was when i looked at it) fairly smart wrt not using more memory than it had to to hold unused translations
[12:19] <seb128> sergiusens, amd64 boots since yesterday for me, it just loops on lightdm
[12:19] <seb128> sergiusens, oh, you need to pick the "ubuntu" entry in grub
[12:20] <Chipaca> mvo: my fear is if we dump app-side translations into a single json or yaml or what have you, we'll load it all in memory all the time always
[12:20] <seb128> not the snappy system-a one
[12:20] <seb128> sergiusens, unsure why there are those different ones
[12:20] <seb128> sergiusens, I hope that with this morning fixes and the new image build we get lightdm to work
[12:20]  * ogra_ glares at jonos last blog post ...
[12:20] <ogra_> ... insane
[12:21] <ogra_> (he suggests we rebase ubuntu on android)
[12:21] <sergiusens> seb128: we are working on getting rid of update-grub fwiw and have very fine tuned grub.cfg's
[12:21] <Chipaca> ogra_: oh no! the person we were taking technical leadership from has lost their mind! what can we do?!?
[12:21] <Chipaca> ogra_: oh, wait
[12:21] <ogra_> haha
[12:21] <ogra_> well, we'd finally get all the great android security !
[12:22] <ogra_> and their battery life too ...
[12:22] <Chipaca> and their juicy, juicy init system
[12:22] <ogra_> oh, yeah !
[12:22] <sergiusens> Chipaca: I prefer manifest_en-ES.yaml or something like that
[12:22] <sergiusens> or dir separated
[12:22] <ogra_> bright the future would be
[12:22] <mvo> Chipaca: yeah, good point
[12:22] <ogra_> :)
[12:22] <sergiusens> whatever makes sense
[12:22]  * sergiusens wants the init system
[12:23] <ogra_> uuuh
[12:23] <sergiusens> and the on disk initrd
[12:23] <ogra_> thats the only one thing i like in android
[12:23] <ogra_> (though there is prior art to that in the terminal server area)
[12:23] <seb128> sergiusens, so for your reboot loop, what grub item do you select?
[12:23] <sergiusens> seb128: I just let the first one to go and go and go, didn't do any manual selection
[12:24] <seb128> sergiusens, btw I keep hitting the loop partition error, unsure why, I need to reboot and retry, it works like 1 every 10 tries, same on my 2 machines :-/
[12:24] <seb128> sergiusens, k, you need to pick "ubuntu" in the list, that's not the top one
[12:24] <sergiusens> seb128: did you try the losetup -d command?
[12:25] <seb128> yes
[12:25] <seb128> but I had deleted the .img when I tried
[12:25] <seb128> and losetup -d didn't seem to work
[12:25] <seb128> loop0 was still listing the deleted image
[12:25] <ogra_> kpartx ;)
[12:26] <ogra_> and dmsetup ...
[12:26] <seb128> and users should have to do that
[12:26] <ogra_> it defaults to a device-manager setup iirc
[12:26] <seb128> the tools should do it for them if that's needed
[12:26] <sergiusens> ogra_: yeah dmsetup clear /dev/mapper/loop0p* ; kpartx -ds /dev/loop0; losetup -d /dev/loop0
[12:26] <ogra_> right
[12:26] <sergiusens> seb128: the dmsetup and kpartx parts are done
[12:27] <ogra_> seb128, yeah, it is a bug that the tool does stop before being able to cleanup
[12:27] <sergiusens> seb128: the losetup isn't, which is why I asked if it helped
[12:27]  * ogra_ hugs the trap function in shell 
[12:27] <sergiusens> ogra_: it is being run, if it was mapped, the unmapping always runs
[12:27] <sergiusens> seb128 try trunk
[12:28] <ogra_> well, it didnt for me when we had the issue recently
[12:28] <seb128> sergiusens, k, going to try in a bit
[12:28] <seb128> sergiusens, but no, losetup didn't help when I tried
[12:28] <ogra_> i had to use dmsetup each time after the error
[12:28] <seb128> but typically I used the tools, hit the error, rm-ed the .img
[12:28] <sergiusens> ogra_: hmm, sometimes dmsetup doesn't work for me either
[12:28] <seb128> in which point loop0 is blocked on the deleted img and losetup seems to do nothing
[12:29] <seb128> ogra_, the same invalid partition count loop error?
[12:29] <sergiusens> ogra_: and I indeed need to reboot and there is no way out of it that I know of
[12:29] <seb128> k, so I'm not alone in the situation ;-)
[12:29] <ogra_> for me dmsetup always worked after making sure i loosely unmounted
[12:29] <seb128> loosely unmounted what?
[12:29] <seb128> how?
[12:30] <ogra_> umount -l
[12:30] <ogra_> (the image)
[12:30] <seb128> k, I guess my error was to delete the buggy img
[12:30] <seb128> to run the command again
[12:30] <seb128> then reboot is needed
[12:30] <ogra_> ah, yeah, but umount -l should still work, ebven with the image gone
[12:30] <seb128> I'm going to try next time
[12:31] <seb128> but why are we hitting those issues in the first place?
[12:31] <seb128> was is flacky?
[12:31] <ogra_> (it will just alter mtab and /proc/mounts ... )
[12:52] <Chipaca> ogra_: you know how the latest wily things aren't bringing up network in kvm?
[12:52] <Chipaca> ogra_: it's because eth0 is now ens3
[12:52] <ogra_> Chipaca, nope, havent heard of that
[12:52] <ogra_> ah, blame pitti !
[12:52] <Chipaca> yep yep
[12:52] <Chipaca> i already do
[12:52] <Chipaca> always
[12:53] <Chipaca> ogra_: i'm not sure why i pinged you, but i thought maybe you'd have ideas as to how to fix it :)
[12:53] <Chipaca> the problem is, of course, that we ship an eth0 interfaces file
[12:53] <Chipaca> when it should be ... something else, i presume
[12:53] <Chipaca> mvo: the good news is, there's an easy workaround to get your kvm wily image working again wrt network
[12:54] <Chipaca> elopio: ^ et vous
[12:54] <ogra_> Chipaca, well, if i knew where that file comes from ...
[12:55] <Chipaca> sergiusens: /etc/network/interfaces.d/eth0 is written by u-d-f
[12:55] <Chipaca> ogra_: ^ i mean you
[12:55] <Chipaca> no way for u-d-f to know the name of the device though
[12:58] <sergiusens> Chipaca: huh?
[12:58] <sergiusens> Chipaca: are you not reading code used by the ubuntu-emulator by any chance?
[12:58] <Chipaca> sergiusens: goget-ubuntu-touch/diskimage/customization.go
[12:59] <sergiusens> Chipaca: yeah, that's ubuntu-emulator
[12:59] <Chipaca> ah
[12:59] <Chipaca> sorry then :)
[12:59] <Chipaca> where does that eth0 file come from then?
[13:00] <sergiusens> Chipaca: on a kvm image?
[13:00] <Chipaca> sergiusens: yes
[13:00] <ogra_> i would suspect something like ubuntu-core-config
[13:00] <ogra_> or a systemd unit thats shipped somewhere
[13:01] <sergiusens> ogra_: Chipaca doesn't look lke ucc http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/ubuntu-core-config/wily/files/head:/etc/
[13:02] <sergiusens> Chipaca: ogra_ dpkg -S says no one owns it
[13:02] <mvo> sergiusens, Chipaca: so gdoc looks mostly sane? I'm a bit torn on /data for system data vs /home/system/data
[13:02] <ogra_> live-build/ubuntu-core/hooks/04-configure_network.chroot
[13:03] <ogra_> there is is i think
[13:03] <ogra_> http://paste.ubuntu.com/11740076/
[13:03] <sergiusens> mvo: I don't like either; it seems /writable/data works better and rids us of a bind mount
[13:04]  * sergiusens wants to just move all refs to /writable
[13:05] <mvo> sergiusens: hm, we would still need the bind mount, unless we move /home/* to /writable/user-data/* (which is probably a good idea in itself)
[13:06] <ogra_> Chipaca, hmm, i fear we need to move that to the boot somehow to detect the actual interface names now
[13:06]  * Chipaca wonders why /writable isn't /var
[13:06] <sergiusens> mvo: I don't mind /writable/home either ;-)
[13:06] <sergiusens> Chipaca: because /var has a lot of read only stuff :-P
[13:07] <sergiusens> maybe /therealvar works bettwe
[13:07] <sergiusens> *better even
[13:07] <Chipaca> sergiusens: it doesn't have that much read only stuff that we don't want to get rid of
[13:08] <ogra_> Chipaca, hyterical raisins ... on android we have /userdata and needed to use that due to not being able to change partitioning on some devices
[13:08] <Chipaca> it's 14M, of which 12M is dpkg/info
[13:09] <mvo> Chipaca: that can be killed, we could do that right now via livecd-rootfs
[13:09] <ogra_> (and we need to share the writable bits with the android container since many bits need to be accessibe by both OSes)
[13:09] <Chipaca> anyway, in the sense that /writable is /var without the things that shouldn't be in /var anyway, we wouldn't be the first unix-like people to put homes in var anyway
[13:09] <ogra_> s/neede/need/
[13:09]  * ogra_ always has home in var on his servers
[13:09] <ogra_> since over a decade :)
[13:10] <sergiusens> Chipaca: ogra_ fwiw, latest images left me without networking on kvm as well
[13:10] <Chipaca> ogra_: i don't know if that should be seen as encouragement or a sign of trouble
[13:10] <ogra_> but that wouldnt help the HW requirements android puts upon us on personal
[13:10] <Chipaca> sergiusens: yes, because of the above
[13:10] <Chipaca> sergiusens: you do have networking, you just don't know it :-p
[13:10] <ogra_> or rather the setup reqs. not the HW reqs
[13:10] <ogra_> we cant change paths of binary blobs
[13:10] <Chipaca> sudo sed -i -e "s/eth0/$(ls /sys/class/net/ | grep -vx lo | head -n1)/g" /etc/network/interfaces.d/eth0
[13:10] <Chipaca> sergiusens: ^
[13:10] <Chipaca> sergiusens: and reboot
[13:11] <sergiusens> mvo: Chipaca let's do that now (remove /var/lib/dpkg) before more people exploit it and then becomes a req to have
[13:11] <Chipaca> sergiusens: or restart networking, but reboot is quicker without ocmpletion :-p
[13:11] <Chipaca> sergiusens: +1.33
[13:11] <ogra_> sergiusens, yes, we hardcode the interface name in livecd-rootfs (pretty bad idea)
[13:11]  * Chipaca is going to run out of .33's if people carry on having good ideas
[13:11] <sergiusens> Chipaca: oh, the iface name change reached us
[13:11] <ogra_> cant we remove dpkg altogether ?
[13:12] <ogra_> even the binary
[13:12] <Chipaca> the whole thing, afaik
[13:12] <sergiusens> ogra_: yes we CAN!
[13:12] <Chipaca> although elopio will be sad
[13:12] <ogra_> JUST DOIT !
[13:12] <Chipaca> we can even remove dpkg-deb
[13:12] <ogra_> JUST DOIT !
[13:12] <ogra_> :)
[13:12] <Chipaca> fuck yeah! break things on fridays!
[13:12] <sergiusens> Chipaca: right,  but the reason we can't remove it on the phone is beacuase QA became entrenched with it
[13:12] <Chipaca> and it isn't even beer o'clock
[13:12] <ogra_> on edge ...
[13:13] <Chipaca> remove it yesterday, then
[13:13] <ogra_> living on the edge you can fall at times :)
[13:13]  * Chipaca puts on a bit of aerosmith
[13:13] <sergiusens> there https://www.youtube.com/watch?v=7nqcL0mjMjw
[13:13]  * ogra_ headbangs 
[13:15] <Chipaca> pitti: you around? wondering if you have bright ideas wrt figuring out the name of the first network device now that it's not static
[13:15] <Chipaca> pitti: currently we have a (now non-functional) static file that brought up eth0 with dhcp
[13:16] <mvo> Chipaca: dmesg|grep eth
[13:16] <Chipaca> mvo: see above for sed that works :)
[13:16] <mvo> Chipaca: oh, sorry
[13:17] <pitti> Chipaca: what is "static" in this context?
[13:17] <Chipaca> mvo: asking because we can't be the first ones, so maybe there's already a known-good soltion
[13:17] <Chipaca> mvo: otherwise we can cook :)
[13:17]  * mvo nods
[13:17] <ogra_> mvo, livecd-rootfs http://paste.ubuntu.com/11740076/ ...
[13:17] <ogra_> but interface names are dynamic now ... on boot ...
[13:17] <Chipaca> pitti: livecd-rootfs writes /etc/network/interfaces.d/eth0 with allow-hotplug eth0\niface eth0 inet dhcp
[13:18] <Chipaca> pitti: see ogra's pastebin for the code that writes it out
[13:18] <mvo> Chipaca: I think apparmor may break without dpkg, the aa-clickhook was iirc calling dpkg for something
[13:18] <ogra_> so we need to move the file cration somewhere into the boto process
[13:18] <ogra_> *boot
[13:18] <ogra_> after we know the name
[13:18] <Chipaca> ogra_: no, no boto! jdstrand will get upset
[13:18] <pitti> Chipaca: and what is "first"?
[13:18] <ogra_> haha
[13:18] <pitti> Chipaca: for ethernet, pick any match in /sys/class/net/en*
[13:18] <pitti> Chipaca: I guess in many cases there will be just one, but as the old persistant-net-generator just randomly picked one to become eth0, you can also just pick the asciibetically first one
[13:18] <pitti> i. e. ls /sys/class/net | head -n1
[13:18] <pitti> ?
[13:19] <Chipaca> pitti: good to know they're en*
[13:19] <ogra_> pitti, is that generator gone ?
[13:19] <mvo> just out of curiosity, why is it erenamd in the first place?
[13:20] <mvo> dmesg tells me it was eth0 before and then got renamed
[13:20]  * ogra_ wonders if we could abuse it to create an alias name for the moment ... as quick fix)
[13:20] <pitti> Chipaca: yes, and wlan is wl*
[13:20] <Chipaca> mvo: i assume, because it's fake anyways, and at least this way it's consistent and you can find it in /sys/ and elsewhere, but i don't know :)
[13:20] <Chipaca> i think there are three different names for the device? or something like that
[13:20] <mvo> but only one that works with ifconfig it seems
[13:21] <seb128> sergiusens, mvo, so we had a new build on https://launchpadlibrarian.net/209509553/buildlog_ubuntu_wily_amd64_ubuntu-desktop-next_BUILDING.txt.gz a bit over an hours ago
[13:21] <pitti> ogra_: yes, see https://lists.ubuntu.com/archives/ubuntu-devel/2015-June/038786.html
[13:21] <seb128> I just created a personal image using udf, but that seems to have given me an outdated version
[13:21] <seb128> like ubuntu-core-config was not at 0.22 which it is in this log ^
[13:21] <seb128> is that normal?
[13:21] <Chipaca> mvo: i mean, the same device is called (potentially) different things in different parts of the system
[13:21] <ogra_> pitti, "this wont affect upgrades" ... also on readonly system-image installs ? :)
[13:22] <seb128> is there a way to check if there a channel image update ongoing and what's the status?
[13:22] <pitti> Chipaca: your sed will also catch wlan, wwan, vlan, and other devices -- I suppose you don't want that, or do you? (I said en* as you had eth0 before)
[13:22] <ogra_> (where the upgrade is actually replacing bits of the system instead of using dpkg)
[13:22] <Chipaca> pitti: the sed was strictly just for our images, running in kvm
[13:22] <Chipaca> pitti: not a general solution
[13:22] <pitti> ogra_: well, upgrades in the apt sense :)
[13:22] <ogra_> pitti, right
[13:22] <sergiusens> seb128: there are logs on nusakan, but I don't recall where to find them
[13:22] <ogra_> so it will break phones and snappy
[13:22] <pitti> we can't have maintscripts on s-i upgrades
[13:22] <ogra_> we need to take that into account i guess
[13:22] <jdstrand> mvo: fyi, click-apparmor doesn't care about anything dpkg-y per se. we have this (rather crappy) mechanism for system-image based systems to discover when click-apparmor (and apparmor and ubuntu-core-snappy-apparmor and apparmor-easyprof-ubuntu) is updated that looks at the dpkg debsums
[13:23] <seb128> ogra_, you might know (logs on nusakan)
[13:23] <pitti> ogra_: how so? there we wouldn't have a writable /etc/ anyway, do we? i. e. we couldn't write the persistant rules?
[13:23] <ogra_> seb128, rootfs build ?
[13:23] <pitti> or firewall rules and stuff which refer to the names?
[13:24] <ogra_> pitti, well, on phones it might not be an issue ... NM cares for the interfaces
[13:24] <seb128> ogra_, no, wondering how to know when the image from https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-desktop-next is going to make it into the personal channel
[13:24] <jdstrand> mvo: the idea is that goes away when snappy stops using aa-clickhook, but we need to figure out another mechanism for detecting these things
[13:24] <ogra_> seb128, /srv/cdimage.ubuntu.com/log/
[13:24] <seb128> ogra_, it built over an hour ago and I just use udf to build and image but get the old content
[13:24] <pitti> ogra_: right, and NM doesn't care about the name
[13:24] <seb128> ogra_, in fact I don't have ssh access to that box so nevermind, I can't look there
[13:24] <ogra_> seb128, there is no logging for system-image
[13:25] <ogra_> (at all)
[13:25] <seb128> I guess I just have to wait and retry?
[13:25] <ogra_> only for cdimage and livefs builds
[13:26] <seb128> version is at 10, I guess I need a 11...
[13:26] <seb128> sergiusens, mvo, you are sure channel images are autoupdated?
[13:26] <sergiusens> seb128: well, slangasek said he added it to the list
[13:27] <sergiusens> seb128: once it's in the list for consumption, it's automatic; only reason it failed could be due to an error
[13:27] <seb128> slangasek, hey
[13:27] <mvo> seb128: import-image is still running
[13:27] <seb128> mvo, how long does that take?
[13:27] <seb128> mvo, is there some UI where I can see the status?
[13:27] <mvo> seb128: TMPDIR=/srv/system-image.ubuntu.com/tmp /srv/system-image.ubuntu.com/bin/import-images -vvvv
[13:27] <mvo> 2015-06-19 13:27:14,522 INFO Something else holds the global lock. exiting.
[13:27] <sergiusens> seb128: from http://system-image.ubuntu.com/ubuntu-personal/rolling/edge/generic_amd64/index.json it seems it was last updated today
[13:27] <seb128> sergiusens, today this morning or today an hour ago?
[13:27] <mvo> seb128: lsof -p 4196 tells me there is no log
[13:28] <sergiusens> seb128: very early Fri Jun 19 06:02:00 UTC 2015
[13:28] <seb128> sergiusens, k, so likely the daily build, no the retry with the fixes from this morning
[13:28] <sergiusens> maybe the phone guys are fooling around with s-i?
[13:28] <seb128> mvo, is that lock warning something I should be concerned about? ;-)
[13:28] <mvo> seb128: no, it means its working
[13:29] <seb128> k
[13:29] <mvo> seb128: ls -lh /srv/system-image.ubuntu.com/tmp/tmpSW4IWr/
[13:29] <mvo> total 3.2G
[13:29] <mvo> -rw-rw-r-- 1 cdimage cdimage 1.8G Jun 19 13:20 source.tar
[13:29] <mvo> -rw-rw-r-- 1 cdimage cdimage 1.4G Jun 19 13:28 target.tar
[13:29]  * seb128 waits then
[13:29] <mvo> seb128: that might help
[13:29] <sergiusens> big images with s-i :)
[13:29] <seb128> mvo, thanks
[13:29]  * seb128 would like to see an image booting before eow!
[13:29] <mvo> seb128: but I share your pain, +1 for logs
[13:29] <sergiusens> and super tight xz compression levels
[13:29] <mvo> seb128: you have 2.5 more days ;)
[13:30] <seb128> mvo, lol
[13:31] <ogra_>  4196 ?        R     28:56 /usr/bin/python /srv/system-image.ubuntu.com/bin/import-images
[13:31] <ogra_> runs since 30min
[13:32] <ogra_> (or rather "had 30min f CPU cycles)
[13:32] <ogra_> *of
[13:33] <Chipaca> f works too
[13:34] <Chipaca> short for the same thing as it was in fvwm
[13:35] <sergiusens> mvo:  golang-gettext-dev is not in the archives yet
[13:36] <mvo> sergiusens: I guess some archive admin needs to get active
[13:36] <mvo> sergiusens: like seb128 …
[13:36] <sergiusens> heh :-P
[13:36] <seb128> lol
[13:36] <seb128> I own you some... sure I can do that ;-)
[13:36]  * mvo hugs seb128
[13:37]  * seb128 hugs mvo back
[13:37] <ogra_> huggers
[13:38] <sergiusens> mvo: another reason to use http://getgb.io/ ;-)
[13:38] <mvo> sergiusens: haha, indeed, it would make all the packaging irrelevant
[13:39] <sergiusens> mvo: I might try and switch webdm given it's not even a debian package :-P
[13:41] <seb128> sergiusens, mvo, NEWed, I'm going to watch for the build and NEW the binaries then
[13:41] <sergiusens> ty
[13:42] <seb128> yw
[13:42] <mvo> \o/
[13:46] <mterry> mvo, golang-gettext landed in wily
[13:49] <ogra_> seb128, oh man, adding your gigantic image makes the system-image importer run forever ...
[13:49] <ogra_> (still busy ... that used to be 10-15min max ... )
[13:51]  * ogra_ thinks we'll need separate s-i servers soon ... image build times wont be bearable anymore at some point
[13:52] <seb128> mvo, read backlog :p
[13:52] <seb128> ups
[13:52] <seb128> mterry, read backlog :p
[13:52] <seb128> ogra_, yeah, sorry about that ...
[13:52] <mvo> ogra_: once we move the os into a snap it will be a different system doing the imports
[13:52] <ogra_> seb128, not your fault, our infra sucks on that level
[13:52] <ogra_> mvo, sure ... but til then every new image and arch adds up
[13:53] <mterry> seb128, thanks!  :)
[13:53] <seb128> mterry, yw ;-)
[13:53] <seb128> mterry, miiiike
[13:53] <seb128> https://launchpad.net/ubuntu/+source/golang-gettext/0~git20130221-0ubuntu1
[13:53] <ogra_> mvo, and phone kind of needs more rapid turnaround time than waiting 3h for an image build
[13:53] <seb128> ftbfs
[13:53] <seb128> mvo, ^ fail to build
[13:54] <mterry> seb128, haha
[13:54] <mterry> seb128, guh those stupid tests
[13:54] <sergiusens> mterry: lol, funny how tests are always stupid when they fail :-)
[13:55] <sergiusens> especially on a Friday!
[13:55] <longsleep> Hey folks, is there a way to run my own image-server and have my images use that one?
[13:55] <sergiusens> longsleep: yes there is
[13:55] <mterry> sergiusens, it's not that they are stupid tests, they are just *being* stupid  :)
[13:55] <longsleep> sergiusens: Ok great - then i have a project for the weekend :(
[13:56] <longsleep> wrong smily - meant :)
[13:56] <sergiusens> longsleep: https://wiki.ubuntu.com/ImageBasedUpgrades/ServerSetup
[13:56] <longsleep> sergiusens: awesome - thanks!
[13:58] <longsleep> currently my images pull generic_armhf - is there a way to make it pull say odroidc_armhf ?
[13:59] <longsleep> i mean i saw that config somewhere in /etc/system.. but can it be set from the oem snap or something?
[14:09] <sergiusens> longsleep: that's the leaf node in system image /etc/system-image/channel.ini
[14:10] <longsleep> sergiusens: Right, but how can it be changed automatically - like when building the image file?
[14:11] <sergiusens> longsleep: that's all part of the server setup, is it not there? if not it is described one level up
[14:12] <longsleep> longsleep: didn't see it - let me look again
[14:12] <ogra_> it will stop working once we switch to snap only upgrades
[14:12] <ogra_> (and away from s-i )
[14:12] <ogra_> no idea whats the ETA on this though
[14:12] <elopio> good morning.
[14:14] <longsleep> ogra_: right - but the base system still needs to come from some place?
[14:15] <ogra_> longsleep, from a snap package ...
[14:15] <ogra_> (in the future scenario)
[14:16] <longsleep> ogra_: mhm i fail to see how this is going to work - then that snap package is not mutch different from a tar.xz
[14:17] <ogra_> it comes from a different place
[14:17] <longsleep> right now i am looking into possibilities how i can let people upgrade their ODROIDC's if i roll a new kernel without flashing
[14:17] <ogra_> right, running your own s-i server is the solution then
[14:17] <sergiusens> elopio: u-d-f should test this combination release_used_to_build release_built release_built_revision $target_device
[14:17] <ogra_> but it wont presist
[14:17] <ogra_> *persist
[14:18] <longsleep> ogra_: right - i understand that - but how long would that actually be? Weeks, months?
[14:18] <ogra_> at one point all three image parts are snaps ... and u-d-f will assemble the image from the store
[14:18] <ogra_> see above: <ogra_> no idea whats the ETA on this though
[14:19] <ogra_> it is on the roadmap ... but i dont know for when
[14:19] <ogra_> (surely before april ... no idea if before october)
[14:19] <longsleep> ogra_: ok :) i see what i can do then with my own system-image-server and it becomes obsolete once its obsolete - i am fine with that
[14:20] <longsleep> the interesting question is if there will be a upgrade path from current system-image installs to store only installs
[14:21] <elopio> fgimenez: I'm joining the talky.
[14:21] <ogra_> that i cant tell
[14:21]  * sergiusens takes a short break
[14:21] <jdstrand> olli: re docs> https://developer.ubuntu.com/en/snappy/guides/security-policy/ (has Debugging at the end), https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement#Debugging, https://developer.ubuntu.com/en/snappy/guides/frameworks/ (discusses framework-policy), https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement/DevelopingFrameworkPolicy (tips for framework authors)
[14:22] <fgimenez> elopio, ok, i'm already there
[14:23] <ogra_> seb128, the importer seems to be done now
[14:23] <seb128> ogra_, indeed, 11 on http://system-image.ubuntu.com/ubuntu-personal/rolling/edge/generic_amd64/
[14:23] <seb128> ogra_, thanks!
[14:23]  * seb128 starts udf build
[14:30] <olli> jdstrand, thx!
[14:45] <elopio> Chipaca: I won't be sad if we can build the image with the ubuntu-snappy-tests deb.
[14:45] <Chipaca> elopio: i have no idea what a deb is. you're talking nonsense.
[14:46] <Chipaca> elopio: there has never been dpkg
[14:47] <elopio> Chipaca: http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/integration-tests/selftest#L50
[14:48] <elopio> that's the ugly workaround we need to solve in a clever way.
[14:51] <elopio> sergiusens: can we pass the ~/.ssh/id_rsa.pub to the image from ubuntu-device-flash ?
[14:52] <elopio> oh, that's --developer-mode.
[14:56] <rickspencer3> jdstrand, I have a much smaller reproducer for the net_admin issue I hit
[14:56] <rickspencer3> I think it might be from reading a yaml file locally
[14:59] <elopio> fgimenez: I was just saying that maybe we need to return to hangouts for the time being.
[15:00] <Chipaca> rickspencer3: i don't know if you saw, but tyhicks narrowed it down quite a lot more
[15:00] <rickspencer3> I saw that
[15:00] <rickspencer3> thanks Chipaca
[15:00] <Chipaca> rickspencer3: to the point there's a kernel patch and all
[15:00] <Chipaca> ah, k
[15:00] <rickspencer3> I put my smaller listing in for good measure, though
[15:00] <Chipaca> rickspencer3: also, stop breaking the kernel :-p
[15:01] <rickspencer3> if by that you mean, "stop using snappy"
[15:01] <rickspencer3> no chance
[15:01] <rickspencer3> I love this stuff
[15:01] <rickspencer3> it's like developing for the phone, but on steroids
[15:03] <Chipaca> oooh, that's nice, kernel dumps on usb unplugs
[15:03] <seb128> sergiusens, mvo, k, new personal build boots to a working unity-greeter ;-)
[15:04] <seb128> with a guest session button
[15:04] <ogra_> seb128, yay
[15:04] <seb128> now I need to try out of a vm for the session because unity8 doesn't work in kvm
[15:04] <ogra_> why didnt you copy the autologin logic from touch ?
[15:05] <seb128> because we started from ubuntu-core
[15:05] <ogra_> (i mean, i know you wont use that in the final thing ... but its likely helpful during porting)
[15:05] <seb128> I should review the diff with touch now
[15:05] <ogra_> yeah, you kind of do a three way merge
[15:07] <jdstrand> rickspencer3: thanks for the extra info
[15:08] <mvo> seb128: \o/
[15:09] <Chipaca> why does eth0 say it's eating 14W when i'm not using it
[15:09]  * Chipaca 's seeing 40W drain on his laptop
[15:09]  * Chipaca would recommend wily to people in colder seasons
[15:09]  * longsleep 's laptop is currently using less power than Chipaca's eth0
[15:10] <Chipaca> :'(
[15:10] <longsleep> :) sorry
[15:10] <Chipaca> well, 18W of that is my hd webcam
[15:13] <sergiusens> seb128: yay
[15:17] <mvo_> sergiusens: there will be conflicts with the noUpdate branc hand the snappy-improved-developer-mode branches - if the that could land I can help with the resolving of conflicts
[15:18] <sergiusens> mvo_: no worries
[15:27] <Chipaca> sergiusens: you're leaving for 5h really?
[15:28] <sergiusens> Chipaca: yes, doctor and errands
[15:28] <Chipaca> sigh
[15:28] <Chipaca> also, damn
[15:28] <ogra_> stop being sick !
[15:28] <sergiusens> Chipaca: 5hr is a stretch
[15:28] <Chipaca> sergiusens: i'll poke mvo, and then poke you
[15:28] <Chipaca> no worries
[15:28] <ogra_> doctors earn enough without you supporting them ...
[15:28] <sergiusens> Chipaca: we can meet after standup
[15:31] <seb128> is there a -v mode to "snappy"?
[15:32] <seb128> "snappy internal-run-hooks" fails on personnal
[15:32] <mvo_> seb128: on wily? that should provide the output of the failed hooks
[15:32] <seb128> "hook command /usr/lib/ubuntu-push-client/click-hook failed with exit status 1 (output: "")"
[15:32] <seb128> mvo_, ^
[15:32] <bschaefer> hello is there a way to make the snappy core system writable to test some packages and doing session stuff? (such as touch /userdata/.writeable?)
[15:33] <seb128> bschaefer, mount -o remount,rw /
[15:33] <bschaefer> seb128, cool thanks!
[15:33] <seb128> yw
[15:33] <seb128> if you want to use apt just rm /usr/local/bin/apt*
[15:33] <seb128> that's handy for local debug
[15:33] <seb128> I used that to install things on personal
[15:34] <bschaefer> o cool sweet!
[15:37] <Chipaca> seb128: bschaefer: but do know that's even less supported than on touch
[15:38] <seb128> Chipaca, "supported"? it helped me to understand why lightdm doesn't start, then I threw away the image and uploaded the ubuntu-core-config fixes neded
[15:38] <seb128> Chipaca, which is just what I needed
[15:38] <bschaefer> its mainly for debuging and to figure out if its possible or not
[15:38] <bschaefer> to do what im trying :)
[15:38] <Chipaca> seb128: yes. I'm wondering how much we learned from people breaking their phones because we publicized things like this.
[15:39] <seb128> Chipaca, discussion development here is not really publicizing to users...
[15:39] <seb128> discussing*
[15:39] <seb128> Chipaca, btw, do you have any idea how to figure out why /usr/lib/ubuntu-push-client/click-hook fails on snappy personal/how to debug?
[15:40] <seb128> it returns "1"
[15:40] <seb128> but without any error/output
[15:41] <ogra_> writability is sadly essential for porting ... on phones at least ...
[15:41] <ogra_> but i agree, we should have never documented it at all
[15:42] <seb128> right
[15:42] <seb128> well, we are discussing on a dev channel
[15:42] <seb128> it's not really documenting
[15:42] <ogra_> well, mount -o remount,rw / is everywhere in phone blogs and docs
[15:43] <seb128> that command existed before ubuntu ...
[15:43] <ogra_> and it isnt hard to adapt that concept to snappy if you look close enough
[15:43] <ogra_> heh, indeed
[15:56] <elopio> Chipaca: so, for when you have some time: http://paste.ubuntu.com/11740844/
[15:59] <Chipaca> elopio: in a hangout right now, but on this right after (will ping you)
[16:09] <sergiusens> elopio: try making it a multi target
[16:09] <elopio> sergiusens: I need a for-dummies explanation of that.
[16:10] <elopio> what should be multi target? the chroot, or the deb, or the command?
[16:14] <mvo_> mterry: is something like https://code.launchpad.net/~mvo/snappy/snappy-binary-ld-library-path-wrapper/+merge/252560 part of snapcraft now? or we just go ahead with that on the snappy side?
[16:17] <fgimenez> nice weekend everyone o/
[16:19] <mterry> mvo_, we envisioned that as something snapcraft did
[16:20] <mterry> mvo_, and especially since we would probably have multiple, namespaced lib dirs
[16:20] <mterry> mvo_, I am also leery as sergiusens of hardcoding layout of a snap
[16:20] <mvo_> mterry: thanks, thats great, if its on your radar thats good enough for me :)
[16:27] <sergiusens> elopio: Multi-Arch: same iirc
[16:27] <sergiusens> elopio: https://wiki.ubuntu.com/MultiarchCross
[16:30] <slangasek> seb128: I'm off today, but if you have a question ask and I'll try to answer :)
[16:31] <seb128> slangasek, no, it's fine, enjoy your day off ... I was wondering if the s-i server would pick new tarballs from cdimage builds, it does
[16:31] <slangasek> seb128: yep, sure does :)
[16:31] <seb128> slangasek, it just took ages
[16:31] <slangasek> ah, it should only take 5 minutes to pick it up, and sometime longer than that to process them
[16:31] <seb128> where ages is like 3 hours
[16:32] <seb128> right
[16:32] <slangasek> so maybe the importer was disabled at the time because of something happening for the phone
[16:32] <seb128> seems like the s-i server mangling is having lot to chew with the personal image ;-)
[16:33] <seb128> slangasek, <ogra_>  4196 ?        R     28:56 /usr/bin/python /srv/system-image.ubuntu.com/bin/import-images
[16:33] <ogra_> slangasek, when i last checked the process it had 48 min on the counter ...
[16:33] <seb128> slangasek, well, maybe 3 hours is exagerated but it was easy > 1.5 hours, seems the imported was eating cpu for over half an hour
[16:33] <ogra_> before it finished
[16:33] <slangasek> ok
[16:33] <slangasek> may not have been just because of the personal images, there may have been other images to import at the same time
[16:34] <ogra_> i was wondering before if we could split phone and snappy imports somehow
[16:34] <seb128> I guess adding the personal images doesn't help, they are not small
[16:34] <ogra_> when we started it was under 10min
[16:34] <seb128> slangasek, also I was unsure what was going on, there is no place to see if an import is ongoing and what's the status afaik
[16:35] <seb128> slangasek, anyway, we eventually got the image out of it and it's booting to a working lightdm, so all good ;-)
[16:35] <ogra_> and it grew by ~5 min for each phone arch we added, i imagine thats similar on the snappy side now
[16:35] <seb128> next step is to test the session, but mir doesn't like my vm so need to switch to real hwd for that, it's for next week
[16:35] <slangasek> Well, yes.  The server where this happens contains sensitive keys; not something that we'd be keen to add a webservice to to let people publically track the importer status
[16:36] <ogra_> right, "ps ax|grep import" on nusakan is the best you can do ...
[16:36] <ogra_> would eb nice to have a constant log from the importer though ... that sets a stamp or some such when itz starts and finishes a run
[16:36] <slangasek> however, any of sil2100, rsalveti, mvo, ogra, myself etc can check the status for you
[16:38] <ogra_> hmm, i guess that would be easy to achieve by just adding -v >>$logfile to the crontab line
[16:39] <seb128> slangasek, yeah, well now I know that it's reacting to new builds and that it takes some time, so it's fine
[16:39] <seb128> slangasek, thanks for the reply, enjoy your day off work ;-)
[16:41] <elopio> not much luck using same. But with python3:any on the dependencies I got a little further.
[16:41] <elopio> http://paste.ubuntu.com/11741070/
[16:51] <Chipaca> elopio: that looks like a bug in python3.4's packaging
[16:51] <Chipaca> elopio: maybe barry can confirm?
[16:51] <Chipaca> /var/lib/dpkg/info/python3.4-minimal.postinst: 46: /var/lib/dpkg/info/python3.4-minimal.postinst: python3.4: not found
[16:51] <Chipaca> barry: ^
[16:51] <Chipaca> that's in wily
[17:05]  * longsleep wants to see Snappy to ship only a single Python and does not care if it is 2 or 3
[17:06] <olli> snappy gods... I am seeing the following issue - http://paste.ubuntu.com/11739849/
[17:06] <olli> with that n dmesg
[17:06] <olli> http://paste.ubuntu.com/11739855/
[17:07] <olli> mterry says access denial to /usr/share/applications might be a red herring however
[17:07] <ogra_> olli, LD_LIBRARY_PATH not set ?
[17:08] <ogra_> (for the first line in the first post)
[17:08] <olli> http://paste.ubuntu.com/11741043/ - line 5083 shows successful access to the library
[17:08] <olli> and the lib exists in the fs
[17:08] <ogra_> /usr/lib/x86_64-linux-gnu/ is definitelky nothing you can ship in a snap
[17:08] <ogra_> not without $SNAPP_APP_PATH prefix
[17:09] <olli> ah
[17:09] <olli> it's deb2snap where it's coming from
[17:09] <olli> but...
[17:09] <ogra_> ah ... mterry terrytory then :)
[17:09] <olli> seems like qt assumes access to the lib in the standard path
[17:10] <ogra_> yeah, while yu would want /apps/mir/snap1/debs/usr/lib/x86_64-linux-gnu
[17:10] <olli> the strace shows successful access due to deb2snap LDpreload magic
[17:10] <olli> ogra check the last pastebin
[17:10] <olli> line 5083
[17:10] <olli> just seems that Qt is printing the err msg
[17:11] <olli> and the printf doesn't know about LDPRELOAD
[17:12] <ogra_> yeah, butu i wonder what else internally doesnt :)
[17:12] <ogra_> *but
[17:12] <olli> ogra_, all access to libdeclarative_multimedia is successful according to the lib
[17:12] <olli> s/lib/strace
[17:14] <ogra_> i think for the /usr/share/application issue there is actually some XDG_* variable you can set to point to the prefixed versin of the dir ...
[17:15] <ogra_> (if qmlscene accepts freedesktop standards :) )
[17:15] <olli> right, not worried about that
[17:42] <mterry> olli, still no luck?
[17:42] <olli> mterry, I got the strace
[17:42] <olli> shows access to the right .so
[17:42] <olli> so I am rtfc
[18:06] <olli> mterry, for the ldpreload redirections, shouldn't I be able to run that locally on my regular system
[18:06] <olli> assuming I am setting the Snappy env vars accordingly?
[18:07] <mterry> olli, I think so?
[18:07] <olli> then I could at least pretend to debug outside of the confined core system
[18:07] <mterry> should work..
[18:07] <olli> will try
[18:12] <barry> Chipaca: i noticed some problems w/ py3.4 in armhf just earlier today and sent an email to doko
[18:22] <olli> does snappy allow me to install snaps outside of "core", eg into a chroot?
[19:05] <elopio> barry: thanks. Please keep me on posted if you get news so I can retry this.
[19:09] <barry> elopio: will do
[19:45] <skay> I think I flashed a beagleboneblack with snappy, and I'm wondering if I should see a new network interface show up when it's plugged in to my computer
[22:34] <Nissyen> Hi, I filed a bug report, but I am not sure if I just rediscovered bug #1460152 .
[22:34] <nothal> Bug #1460152: apparmor cache not updated when apparmor.d rules change (breaks 15.04/stable -> 15.04/edge updates) <Snappy:Fix Committed> <apparmor (Ubuntu):New> <http://launchpad.net/bugs/1460152>
[22:34] <Nissyen> The bug I filed was #1466682
[22:37] <Nissyen> Does anyone know if a unix socket permission issue would be another manifestation of apparmor not rebuilding the cache?
[22:40] <jjohansen> Nissyen: maybe, is apparmor denying access to the socket
[22:40] <jjohansen> Nissyen: if the cache is out of date and you are using old policy it is possible
[22:40] <Nissyen> Yeah, the dmesg is: [   72.230872] audit: type=1400 audit(1434397079.776:12): apparmor="DENIED" operation="connect" info="Failed name lookup - disconnected path" error=-13 profile="docker_docker_1.6.1.002" name="run/docker.sock" pid=1025 comm="docker.x86_64" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=0
[22:41] <jjohansen> Nissyen: you can always just delete the cache and force a policy reload
[22:41] <Nissyen> I reloaded the framework in question, but actually let me try updating ubuntu-core from 2 to 3 on a VM and then rebuilding the cache and see if that fixes it.
[22:41] <jjohansen> Nissyen: I would have to see the policy, but my guess if this requires a policy update
[22:42] <Nissyen> It's the docker policy… I am unfortunately not that familiar with it.
[22:42] <jjohansen> Nissyen, I am not really familiar with the docker policy either
[22:43] <jjohansen> that being said, since this is failing with "Failed name lookup" the policy requires, flags=(attach_disconnected) in it
[22:43] <jjohansen> that would look something like
[22:43] <jjohansen> profile X flags=(attach_disconnected) { ... }
[22:44] <Nissyen> ok, I am setting up a new Vagrant snappy VM, let try to find the policy.
[22:46] <Nissyen> ir has a line "/eun/@{APP_PKGNAME}.sock rw,
[22:47] <Nissyen> sorry, The line is as follows:
[22:47] <Nissyen>  /run/@{APP_PKGNAME}.sock rw,
[22:48] <Nissyen> let me try rebuilding and see what happens, I did a core update to cause the permission issue.
[22:54] <Nissyen> sudo apparmor_parser --skip-cache -r /etc/apparmor.d/usr.bin.ubuntu-core-launcher did not resolve the issue. Maybe this is a new apparmor related bug
[23:06] <Nissyen> Aha! I found that running the command "sudo aa-clickhook -f" worked