[06:51] <dholbach> good morning
[06:53] <mvo> hey dholbach, good morning!
[06:53] <miken> Morning mvo, dholbach o/
[06:56] <dholbach> hi mvo, hi miken
[07:04] <mvo> hey miken
[07:43] <davidcalle> Morning all
[07:48] <D_Cent> help! my snappy won't let me install any snaps anymore - it always says "Warning: failed to remove /apps/<snap name>/<version>: '%s'". i don't know what that means but it doesn't install anything anymore :( any ideas on this=
[07:48] <D_Cent> * ?
[07:51] <mvo> D_Cent: uh, thats all its saying? no more information? thats bad. what snap is that that you try to install?
[07:51] <mvo> D_Cent: this sounds like the "garbage collect" feature is broken for some reason
[07:52] <mvo> D_Cent: and it happens for every snap you said?
[07:52] <D_Cent> mvo: yeah, for everything - the exact message is e.g.:
[07:52] <D_Cent> (just a sec)
[07:53] <mvo> D_Cent: no rush, I'm here for at least 8 more hours :)
[07:53] <D_Cent> good :) the message is: "2015/05/26 07:53:17 Warning: failed to remove /apps/webdm/0.6.1: %!s(<nil>)"
[07:54] <D_Cent> followed by: "webdm failed to install: exit status 1"
[07:57] <mvo> D_Cent: could you please pastebin "snappy list -v" ? is this a VM? if there is nothing "valuable" in it, could you make it available for download so that I can dig into it?
[07:57] <mvo> (it being the VM if it is one)
[08:01] <D_Cent> mvo: sure, here it is: http://pastebin.com/VXATTzaH it's a raspberry pi 2. unfortunately, i can't make it public because the device and software belongs to the company i work for :/
[08:02] <mvo> D_Cent: sure, understood!
[08:03] <mvo> D_Cent: thanks, so now you install webdm (or anything else) and it fails with the above message, correct? let me dig into the source and I will come back with more questions
[08:04] <D_Cent> mvo: correct - thank you very much :)
[08:11] <mvo> D_Cent: could you please edit /etc/system-image/channel.ini and set channel: to "ubuntu-core/15.04/edge" instead of the current "ubuntu-core/15.04/stable"? this should give you a updated version of the 15.04 image that has much improved error reporting. with a snappy update and a snappy reboot you could have the update version. its still based on 15.04 and is going to become a official update in some days
[08:15] <D_Cent> mvo: the problem is that the raspberry pi 2 currently cannot update :/
[08:15] <mvo> D_Cent: uh, once sec, you will need to "mount -o remount,rw /" the system first of course and you will also need to do the same for /writable/system/cache which holds the "other" parition of the snappy dual-partition layout
[08:15] <mvo> D_Cent: meh, ok
[08:15] <mvo> D_Cent: well, then we need to just update snappy in isolation :)
[08:16] <mvo> D_Cent: please do "sudo mount -o remount,rw / ; sudo /usr/bin/apt update; sudo /usr/bin/apt install ubuntu-snappy ; sudo mount -o remount,ro /"
[08:16] <mvo> D_Cent: that should give you the new snappy with the better error reporting
[08:20] <D_Cent> mvo: and i don't destroy anything with that?
[08:21] <mvo> D_Cent: no, but if you prefer a different approach, thats fine, one sec
[08:22] <mvo> D_Cent: do (cd /tmp ; wget https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/7401399/+files/ubuntu-snappy-cli_1.0.1-1%2B439%7Eubuntu15.04.1_armhf.deb; dpkg-deb -x *.deb .)
[08:23] <mvo> D_Cent: this should give you /tmp/usr/bin/snappy that you can run and that hopefully gives the improved error messages and a clue what is wrong
[08:24] <D_Cent> aah thank you :) trying that
[08:25] <Chipaca> mo'in
[08:26] <D_Cent> mvo: now it says (for webdm): "open /apps/webdm/0.6.1/www/public/images/app-placeholder.svg: permission denied" followed by "webdm failed to install: unpack /tmp/webdm918031435 to /apps/webdm/0.6.1 failed with exit status 1"
[08:29] <Chipaca> D_Cent: and if you install something that isn't webdm?
[08:29] <D_Cent> Chipaca: for my own package that i install locally, it says "/home/ubuntu/mdnsd_1.0_armhf.snap failed to install: hook command /usr/bin/aa-clickhook failed with exit status 1"
[08:30] <Chipaca> D_Cent: and if you install, say, xkcd-webserver?
[08:31] <D_Cent> Chipaca: also "xkcd-webserver failed to install: hook command /usr/bin/aa-clickhook failed with exit status 1"
[08:32] <Chipaca> hmm
[08:33] <Chipaca> D_Cent: and “/usr/bin/aa-clickhook --help” works?
[08:36] <Chipaca> D_Cent: hold on, what's mdnsd? is that one from the store?
[08:36] <mvo> my theory is that there is a incorrect apparmor file
[08:36] <Chipaca> mvo: yeah, my next step was --froce, to rebuild them all
[08:37] <Chipaca> but still waiting for --help
[08:37] <mvo> what does "aa-clickhook --debug" yield?
[08:37] <mvo> sure :)
[08:37] <Chipaca> mvo: we should have a 'check' or somesuch that checks all files against hashes
[08:37] <mvo> (if --debug is helpful I wonder if thats what we should do when we run hooks and present the stdout/stderr as part of the error)
[08:37] <Chipaca> to ketch broken sd cards
[08:38] <mvo> Chipaca: yeah, very much so, I like that idea a lot
[08:42] <D_Cent> sorry, i was in a meeting - "/usr/bin/aa-clickhook --help" gives me "Usage: aa-clickhook [options]... (etc) (options -f, -h, -d, --include)"
[08:43] <D_Cent> Chipaca: --debug outputs nothing
[08:43] <Chipaca> D_Cent: what about “sudo /usr/bin/aa-clickhook --force”
[08:43] <D_Cent> Chipaca: it finishes in a second, outputs nothing and exits with status 0
[08:44] <Chipaca> well, that's fun :-(
[08:44] <D_Cent> :(
[08:45] <Chipaca> mvo: ideas?
[08:47] <mvo> meh
[08:47] <mvo>  so  /usr/bin/aa-clickhook --force && echo "all good" works? i.e. it also has a zero exitcode?
[08:48] <D_Cent> mvo: exactly
[08:48]  * mvo scratches head
[08:49] <mvo> Chipaca: I think I will add some code to the hook runner that captures the output and presents it to us, maybe that gives us a clue
[08:56] <mvo> D_Cent, Chipaca: in 5min or so a new snappy build should be available for testing (waiting for my cross toolchain to finish installing)
[08:57] <D_Cent> mvo: thank you! can you post me the link to the deb file again then?
[09:01] <mvo> D_Cent: http://people.canonical.com/~mvo/tmp/D_Cent/ contains the snappy binary and my gpg signature (if you want to verify the download)
[09:03] <D_Cent> mvo: okay, this is the output now: http://pastebin.com/1sxzB6La
[09:04] <D_Cent> mvo: the file "abstractions/mdns" really does not exist here
[09:04] <mvo> D_Cent: ha! that gives us some clue :)
[09:04] <D_Cent> mvo: looks good :)
[09:04] <Chipaca> mvo: ⁵!
[09:05] <mvo> D_Cent: I have that file in /etc/apparmor.d/abstractions/mdns - for you its not there you say?
[09:05] <mvo> Chipaca: looks like I need to push a branch with that improvement :)
[09:05] <mvo> Chipaca: and ^5 back !
[09:05] <D_Cent> mvo: yeah, i don't know why - i didn't do anything, but it seems to be in the image i applied on my SD card a month ago
[09:06] <ogra_> did you manually edit any files in the webdm folder ?
[09:06] <D_Cent> ogra_: no :)
[09:06]  * ogra_ has seen that error when files were root owned in an app folder
[09:06] <D_Cent> mvo: can you pastebin me this file please? :)
[09:07] <mvo> D_Cent: good question what happend, maybe some sort of corruption :/ sd cards can be fragile
[09:08] <mvo> D_Cent: the other thing thats strange is the webdm error, but maybe that is a red-herring and it does away once the mdns file is back, I will make it availale for you
[09:08] <mvo> D_Cent: http://paste.ubuntu.com/11367079/
[09:09] <D_Cent> mvo: thank you :)
[09:10] <D_Cent> mvo: everything is working now :) webdm, xkcd-webserver, my own packages...
[09:11] <D_Cent> mvo, Chipaca: thank you very, very much for your help! you saved me :)
[09:11] <Chipaca> D_Cent: you've got it backwards!
[09:11] <Chipaca> D_Cent: you helped us :)
[09:12] <Chipaca> D_Cent: snappy is better thanks to you
[09:12] <Chipaca> D_Cent: so thank *you* very much!
[09:12]  * mvo hugs D_Cent
[09:12] <D_Cent> Chipaca: that's why i like this community ;)
[09:12] <mvo> Chipaca: \o/ exactly right!
[09:13] <D_Cent> everyone is helping everyone :)
[09:13] <Chipaca> now, back to figuring out what to call a method that checks things are ok to install a package
[09:13] <JamesTait> Good morning all; happy Tuesday, and happy Lindy Hop Day! 😃
[09:13] <Chipaca> InstallCheck sounds like you're installing checks. CheckInstall sounds like you're checking and existing install.
[09:13] <Chipaca> CheckForInstall?
[09:14] <mvo> InstallOK?
[09:14] <Chipaca> JamesTait: what ... what is a lindy hop?
[09:14] <mvo> CanInstall?
[09:14] <Chipaca> mvo: wfm :)
[09:14] <mvo> CheckIfInstallIsOkOrNotOrMaybe
[09:15] <Chipaca> PleasePleaseMakeTheInstallPainGoAway
[09:15] <Chipaca> KThxBye
[09:15] <mvo> CheckIfInstallIsOkOrNotAndAlsoLogAndComputeSomeRaondomStuff
[09:15] <mvo> :)
[09:15]  * mvo hugs Chipaca
[09:15] <mvo> I llike KThxBye, we should have this somewhere
[09:15] <JamesTait> Chipaca: energetic, jazzy, swing dance. I've never done it, but it looks quite fun.
[09:16] <mvo> JamesTait: you made me watch a yt video of a 1960 lindy hop competition now. its … interessting
[09:17] <JamesTait> mvo, I may be mistake, but I think our very own Mr Westby participates.
[09:17] <JamesTait> s/mistake/mistaken
[09:17] <mvo> JamesTait: aha! I remembered it from somewhere and was wondering where I had heard it. fun!
[09:17] <mvo> he will have to do a demo on the next sprint :)
[09:18] <beowulf> Chipaca: is it possible, or planned, in snappy/webdm to cancel an install at the download phase?
[09:19] <mvo> we have no support for this in the library yet I think but its a nice feature
[09:19] <Chipaca> beowulf: that is something that would be easy to implement, but is not implemented yet
[09:19] <beowulf> it seems like a thing webdm would like to have
[09:19] <Chipaca> beowulf: create a card for it?
[09:20] <beowulf> Chipaca: will do
[09:20] <Chipaca> ta
[09:22] <beowulf> ok, what's the difference between backlog and todo in the trello?
[09:28] <mvo> beowulf: backlog is the big heap and todo is (in theory) the things to work on next. but its a bit muddled as we also have must-do
[09:29] <beowulf> mvo: ack, i added ^ plus one other to backlog
[09:37] <davidcalle> dholbach, I'm looking at your tools docs, can I start reviewing/integrating?
[09:39] <dholbach> davidcalle, not quite yet
[09:39] <davidcalle> dholbach, ok :)
[09:39] <dholbach> davidcalle, for node-snapper I still have to talk to ogra_
[09:40] <dholbach> and for the python doc I'd like to summarise it some more
[09:40] <dholbach> davidcalle, did you have any general feedback about it?
[09:40] <ogra_> i think node-snapper still needs some final SNAPP/SNAP changes
[09:41] <dholbach> ogra_, is there a but about it or do you know what the issue is?
[09:42] <ogra_> no, no bug ... its just cosmetic ... SNAPP_ vars are still supported afaik ... but will go away
[09:42] <dholbach> oh ok... so just a case of renaming?
[09:43] <ogra_> right in the start-service.sh script that gets produced
[09:46] <Chipaca> beowulf: mvo: plus there's a whole another board of backlog i think
[09:46] <Chipaca> beowulf: mvo: but i'd ask rsalveti about that one
[11:25] <beowulf> simple review, add prettified bytes to snap model in webdm https://code.launchpad.net/~stephen-stewart/webdm/show-download-or-installed-size/+merge/260126
[11:25] <beowulf> (no css!)
[11:32] <Chipaca> beowulf: are you intentionally dropping the “add change:message” thing?
[11:32] <sergiusens> mvo: Chipaca the webdm error is probably from changing from type app to type framework
[11:33] <beowulf> Chipaca: yes, because i'm using parse rather than add... and sorry, i've just spotted a problem :(
[11:34] <Chipaca> beowulf: k
[11:52]  * Chipaca -> lunch and such, bbiab
[11:53]  * Chipaca uploads the current branch to https://code.launchpad.net/~chipaca/snappy/clickety for if people want to take a peek. Not ready yet though.
[11:55] <beowulf> Chipaca: when you get back, https://code.launchpad.net/~stephen-stewart/webdm/show-download-or-installed-size/+merge/260126
[12:02] <sergiusens> Chipaca: can you think of why this is like it is http://paste.ubuntu.com/11369583/ ?
[12:03] <sergiusens> Chipaca: the 3 snaps there were installed with webdm
[12:05] <Chipaca> sergiusens: interesting
[12:05] <Chipaca> sergiusens: on the same version of snappy and webdm?
[12:06] <Chipaca> sergiusens: webdm and hello-dbus-fwk are using a dbus launcher that's created a private /tmp for them
[12:07] <Chipaca> sergiusens: pastebinit.mvo hasn't
[12:07] <Chipaca> sergiusens: but pastebinit.mvo might be older
[12:07] <Chipaca> sergiusens: do a find -ls instead of  ... whatever you did there :)
[12:07] <Chipaca> so i see the dates
[12:07] <sergiusens> Chipaca: I did a find with -printf
[12:08] <Chipaca> sergiusens: find -ls is less work :)
[12:08] <sergiusens> Chipaca: http://paste.ubuntu.com/11369660/
[12:09] <sergiusens> Chipaca: it seems anything launched by webdm inherits webdm's tmpdir
[12:09] <sergiusens> Chipaca: is that the desired behavior?
[12:10] <Chipaca> ah! i think i got it
[12:10] <Chipaca> /tmp/snaps/pastebinit.mvo/1.4.0.0.2/tmp is created by the bin wrapper
[12:11] <Chipaca> the the launcher launches
[12:11] <Chipaca> and creates the "right" /tmp/snap.1000_pastebinit.mvo_SFbTYJ as the tmpdir
[12:11] <Chipaca> and then sets that to the actual /tmp/ and all is well
[12:12] <sergiusens> mterry: in case you want to look at making the core go based http://npf.io/2015/05/pie/
[12:12] <sergiusens> Chipaca: so what is at fault with these embedded tmp dirs? the service?
[12:13] <Chipaca> sergiusens: /tmp/snap.0_webdm_KhJhaT/snaps/webdm/0.6.1/tmp is fine, it's webdm creating and using /tmp/snaps/webdm/0.6.1/tmp as its tmpdir when it's already got a private /tmp/
[12:13] <Chipaca> sergiusens: we could drop the tmpdir from webdm as it's handled by the launcher, but we don't have to
[12:14] <Chipaca> sergiusens: but also apparently webdm uses /tmp/snaps as the place to which to download things from the store?
[12:14] <sergiusens> Chipaca: well, only in rolling, we still need to suport both
[12:14] <sergiusens> Chipaca: it uses tmpdir as defined in launchpad.net/snappy/snappy
[12:15] <Chipaca> sergiusens: which is why you have /tmp/snap.0_webdm_KhJhaT/snaps/docker031408365 (which webdm would see as /tmp/snaps) with what i presume is a docker package
[12:15] <sergiusens> Chipaca: right!
[12:15] <mterry> sergiusens, I imagine we could use a "run an executable" interface vs "load a plugin" if we really wanted language independence too (I bet it would be nice to let each language plugin be written in the respective language if that would be easiest)
[12:16]  * sergiusens nods
[12:16] <mvo> +1 for "run a executable"
[12:16] <mvo> an executable
[12:16] <Chipaca> sergiusens: and /tmp/snap.0_webdm_KhJhaT/snaps/.gmx.808.0 is davecheney's mdns thing
[12:16] <sergiusens> Chipaca: yes, I'm not worried about those ;)
[12:17] <Chipaca> sergiusens: so, in answer to your question, things that webdm installed are not inheriting webdm's tmpdir, no
[12:17] <sergiusens> Chipaca: just the embedded packages, but it is the actual packages, I didn't look at the file attribs carefuly
[12:17] <Chipaca> sergiusens: otherwise you would have /tmp/snap.0_webdm_sarasa/snap.1000_pastebinit.mvo_sarasa/....
[12:18] <Chipaca> sergiusens: note how it's the new private tmpdir, snap.$UID_appname_random, and the old tmpdir snaps/appname/version/tmp
[12:18] <sergiusens> beowulf: one of your MPs setup for review depends on this one which is on hold https://code.launchpad.net/~stephen-stewart/webdm/icons-icons-icons/+merge/259800
[12:19] <Chipaca> and now, i think i'm going to go to get my lunch for real
[12:19] <Chipaca> otherwise it'll be high tea instead of lunch :)
[13:09] <mvo> sergiusens: was there anything new about the "FAT-fs (mmcblk0p1): IO charset iso" error from last week? I'm look at this right now and wonder if I missed anything
[13:09]  * Chipaca goes back to bashing installClick into submission
[13:10] <rsalveti> o/
[13:10] <sergiusens> mvo: I don't think so, I went MIA after the standup on Friday
[13:10] <sergiusens> beowulf: I tested query again and it works fine (from a webdm PoV)
[13:10] <mvo> sergiusens: :) ok, no worries, I have some theories and will have a look
[13:10] <sergiusens> beowulf: for some reason Chipaca's package makes the store return more results (even though it's super specific)
[13:11] <sergiusens> nessita: any idea?
[13:11]  * ogra_ thinks the charset error is just fallout of a corrupt partition
[13:11] <mvo> ogra_: sergiusens had it as well
[13:11] <sergiusens> nessita: context: searching for 8nzc1x4iim2xj1g2ul64 returns some apps that don't feel should be part of it
[13:11] <sergiusens> ogra_: I had it, yes
[13:11] <Chipaca> mvo: did you or sergiusens fsck up the partition once it was throwing those errors?
[13:11] <ogra_> mvo, sure, but i dont think it is actually a charset thing
[13:11] <beuno> sergiusens, can you pastebin what the request looks like?
[13:12] <Chipaca> mvo: sergiusens: fsck -p, not fsck up. It was already fscked up.
[13:12] <sergiusens> beuno: I fail to curl it up, but https://search.apps.ubuntu.com/api/v1/package/?q=8nzc1x4iim2xj1g2ul64 with all the headers
[13:12] <Chipaca> mvo: sergiusens: both the mmcblk0p1, and the partition that would normally hold that .ko
[13:13] <Chipaca> fsck ALL the things
[13:13] <beuno> sergiusens, well, the headers is what will tell us what's going on  :)
[13:13] <beowulf> sergiusens: ack, sorry, i'm feeling unwell so going to lie down for a bit
[13:13] <sergiusens> Chipaca: hmmm, so the .ko is on system-b
[13:13] <ogra_> Chipaca, why would a partition hold the .ko ...
[13:13] <sergiusens> beuno: how do you set headers with curl, -H ?
[13:13] <Chipaca> ogra_: well, something's got to hold it :)
[13:13] <ogra_> for necessary filesystems all modules need to be in the initrd
[13:14] <beuno> sergiusens, -H
[13:14] <beuno> sergiusens, curl -sH 'X-Ubuntu-Frameworks: ubuntu-core-15.04-dev1' https://search.apps.ubuntu.com/api/v1/search?q=hello
[13:14] <beuno> for example
[13:14] <sergiusens> beuno: if that's the case, it should look like curl -H "X-Ubuntu-Frameworks: ubuntu-core-15.04-dev1" -H "X-Ubuntu-Release: 15.04-core" -H "X-Ubuntu-Architecture: amd64" 'https://search.apps.ubuntu.com/api/v1/package/?q=8nzc1x4iim2xj1g2ul64'
[13:16] <nessita> sergiusens, checking
[13:17] <sergiusens> nessita: beuno here's the right copy paste: curl -H "X-Ubuntu-Frameworks: ubuntu-core-15.04-dev1" -H "X-Ubuntu-Release: 15.04-core" -H "X-Ubuntu-Architecture: amd64" 'https://search.apps.ubuntu.com/api/v1/search?q=8nzc1x4iim2xj1g2ul64'
[13:17] <nessita> sergiusens, I was about to say that /packages/ was not a search endpoint :-)
[13:17] <sergiusens> nessita: yeah, it was the part where I was failing to curl :-P
[13:17] <mvo> ogra_, sergiusens: fun! it appears like the initrd and kernel version went out of sync.
[13:18] <nessita> sergiusens, try this https://search.apps.ubuntu.com/api/v1/search?q=%228nzc1x4iim2xj1g2ul64%22
[13:18] <mvo> sergiusens: if you could boot your system and tell me "uname -a" and "ls -l /lib/modules/" that would be cool
[13:18] <nessita> ie, with double quotes, I'll explain why
[13:18] <mvo> sergiusens: your broken one
[13:18] <ogra_> mvo, ah !
[13:18] <ogra_> then the charset is indeed a valid complaint :)
[13:18] <mvo> yes
[13:19] <sergiusens> mvo: I need to recreate the env, but sure
[13:19] <ogra_> mvo, that brings up an ancient plan from me ... putting modules into a separate overlay img that we mount inside the initrd ...
[13:19] <sergiusens> mvo: but I was testing on 15.04, so being out of sync on 15.04 doesn't sound good
[13:20] <ogra_> because else your only option would be to regenerate the initrd on the fly to get the new modules inside on kernel upgrades
[13:20] <mvo> sergiusens: well, yes, one more reason to get to the bottom of this
[13:20] <mvo> :)
[13:20] <sergiusens> nessita: nice catch, I'll update lp:snappy to add what I presume are quotes
[13:20] <mvo> sergiusens: is it a lot of work for your to re-create? or do you still have the sd card?
[13:21] <nessita> sergiusens, our package index performs analysis for both the data being indexed, and the search term. The analysis, among other things, try to parse the given string to take out the most relevant part and also search for derivates
[13:21] <sergiusens> mvo: let me check, I need to move away from the couch though :-)
[13:21] <nessita> sergiusens, in this case I understand since the string is kind of "non sense" it searches some characters, such as the numbers
[13:21] <mvo> sergiusens: haha
[13:22] <jdstrand> dholbach, davidcalle: hey, a week or two back, I asked about updating https://developer.ubuntu.com/en/snappy/guides/frameworks/, https://developer.ubuntu.com/en/snappy/guides/package-metadata/ and https://developer.ubuntu.com/en/snappy/guides/security-policy/
[13:22] <sergiusens> nessita: well now I am confused, not sure we should add this or take advantage of the backend and just blame Chipaca! :-)
[13:23] <nessita> sergiusens, I would say the second :-)
[13:23] <nessita> sergiusens, using quotes all the time is a bad idea, quotes mean exact match
[13:23] <sergiusens> nessita: it's nice to blame Chipaca sometimes, but my troll hat has been off for a while :-P
[13:23] <nessita> and I don't think you'd like that?
[13:23] <mvo> is it just me or does "ci-info: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!Route info failed!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!" look a bit excessive when it comes to "!" - I'm talking to you cloudinit
[13:24] <jdstrand> dholbach, davidcalle: I think the security one may be ok... looking at the logs it seems I only card about the formatting and you fixed it. but the other two weren't updated
[13:24] <sergiusens> nessita: right, so then beowulf using the strange package name for searching is a bad idea
[13:24] <sergiusens> for testing it at least
[13:24] <davidcalle> jdstrand, we must have missed that. Checking.
[13:24] <sergiusens> as in eyeball testing
[13:25] <sergiusens> jdstrand: we agreed that for docs, the team would only update from the 15.04 series and that trunk would roll with what comes next though
[13:25] <nessita> sergiusens, indeed. Ideally, a user will search for keywords, such as "news" and we want to include results for "newspaper" for example
[13:25]  * ogra_ hopes that eyeball testing doesnt involve needles, pins or fingers ...
[13:25] <jdstrand> sergiusens: I missed that point. where is the 15.04 series branch?
[13:26] <dholbach> thanks davidcalle
[13:26] <sergiusens> jdstrand: lp:snappy/15.04
[13:26]  * jdstrand prepares an MP
[13:26] <sergiusens> jdstrand: it's basically to have stable docs; at least it's what I caught from the uos session, dholbach or dpm and confirm
[13:27] <jdstrand> that's fine and makes sense. the stuff I have is all 15.04 anyway
[13:28] <rsalveti> yeah, for trunk we want something more automated
[13:28] <rsalveti> still need to think how to do that properly
[13:31] <sergiusens> mvo: do you see that error that utlemming mentioned on snappy-devel@? I see it too and I wonder if it's trusty thing
[13:32] <sergiusens> mvo: I'm also reconsidering going back to chroot [] snappy install (to alleviate the differences between 15.04 and rolling).
[13:33] <davidcalle> dholbach, I'm reopening the snappy doc sprint trello to have a look at an old card, closing it back after that, don't freak out :D
[13:34] <dholbach> sure, don't worry :)
[13:39] <mvo> sergiusens: looks a lot like a trusty thing, we need this "re-generate sc profiles on boot so that we can inhibit this just like we do for apparmor
[13:45] <Chipaca> mvo: re-generate *all* the things
[13:46] <mvo> sergiusens, ogra_: so it appears the issue I see with my broken boot on BBB is releated to the kernel update from -15 to -16. it boots with -15 but find only the modules for -16 in /lib/modules (because thats what the new system is using)
[13:46] <Chipaca> mvo: sc, apparmor, scripts, systemd service whatsits
[13:46] <Chipaca> s/scripts/wrappers/
[13:46] <mvo> Chipaca: +100
[13:46] <ogra_> mvo, yeah, it would have to re-gen the initrd
[13:46] <ogra_> which we cant really do :/
[13:47] <ogra_> mvo, /lib/modules shouldnt matter in that case since youur issue is when mounting from the initrd
[13:49] <mvo> sergiusens, ogra_: and for extra fun there is this bug that breaks fallover totally that the first reboot brings you to the good partition and the second boot to the bad one (fortunately sergiusens fixed this one)
[13:50] <ogra_> well, i would really like us to find a way to make the initrd actually arch agnostic ...
[13:50] <ogra_> well, perhaps not arch, but version ...
[13:52] <mvo> ogra_: fwiw, we have the updated initrd it just does not get installed because of some brokenness in the snappy code that is responsible for this :(
[13:53] <ogra_> aha
[13:53] <ogra_> so we know the root cause even ...
[13:53] <mvo> I hope so, digging into it now
[13:53] <rsalveti> how are we managing the kernel update regarding the 2 partitions we have?
[13:54] <rsalveti> I'd imagine we would also want a fallback for kernel updates
[13:54] <ogra_> well, that is the a/b model
[13:54] <mvo> rsalveti: there is code in snappy called "handleAssets and syncBootloaderFiles" that will check if there is a new kernel and copy that into the right place (unless it does not)
[13:54] <ogra_> and it apparently works ...
[13:54]  * ogra_ remembers sergiusens' video
[13:54] <rsalveti> mvo: right, but will that reflect at both a and b?
[13:54] <sergiusens> rsalveti: we have a fallback, yes; but it's all one thing today (ubuntu + kernel)
[13:55] <rsalveti> or are we aligning the kernel snap with os?
[13:55] <jdstrand> dholbach: fyi, https://code.launchpad.net/~jdstrand/snappy/15.04-docs/+merge/260161
[13:55] <mvo> rsalveti: right now its aligned with the OS
[13:55] <mvo> rsalveti: and in theory we have /boot/uboot/a that matches what OS-a needs and the same for b
[13:56] <rsalveti> right, got it
[13:56] <jdstrand> dholbach: that has the doc updates for the 3 files that correspond to the 3 pages that should be updated
[13:56] <rsalveti> mvo: would that also contain the modules?
[13:56] <rsalveti> as that can be quite big
[13:56] <elopio> good morning.
[13:56] <mvo> rsalveti: it contains the initrd, the modules are right now part of the system-{a,b} partitions, not part of system-boot
[13:56] <rsalveti> morning elopio
[13:57] <dholbach> davidcalle, did you see https://code.launchpad.net/~jdstrand/snappy/15.04-docs/+merge/260161 as well?
[13:57] <mvo> hey elopio!
[13:57] <jdstrand> mvo: fyi, after I finish the hashes.yaml (which is almost done) I plan to move to the sc regen on boot stuff
[13:57] <mvo> elopio: sorry that I have not replied to your questions in the MP about merging the selftests yet
[13:57] <mvo> jdstrand: \\o//
[13:57] <dholbach> davidcalle, I'm currently busy finishing something else - let me know if you want me to take care of the above...
[13:57] <mvo> jdstrand: great news, you ROCK
[13:57] <jdstrand> davidcalle: all we need is https://code.launchpad.net/~jdstrand/snappy/15.04-docs/+merge/260161. that contains everyhting I want updated on the website
[13:58] <davidcalle> dholbach, I'm enhancing the small script we had to convert doc, I'll look at it in a short moment, thanks for the heads up!
[13:58] <rsalveti> mvo: right, need to play a bit more to better understand the ins and outs
[13:58] <elopio> mvo: no problem, mostly things for the future, and I have plenty of things to do around it as it is anyway. The only thing I would like to know before getting it into trunk is about signing the deb.
[13:58]  * dholbach hugs davidcalle
[13:59] <mvo> rsalveti: no worries, its all going to change anyway when we make os/kernel independent
[13:59] <rsalveti> jdstrand: nice, thanks for the doc updates
[13:59] <mvo> elopio: cool, I will look into this
[13:59] <jdstrand> np
[13:59] <rsalveti> mvo: right, that's why I wanted to understand this better :-)
[14:00] <ogra_> i think we should have the modules in a separate overlay
[14:00] <mvo> :)
[14:01] <ogra_> one that even the initrd can see, so we dont need to ship them inside (deduplication at its best :) )
[14:01] <mvo> ogra_, rsalveti: its a bit of a challenge when we make them indepedent as the kernel contains userland stuff as well (nvidia user-space libs potentially etc). so it needs to be merged and I don't really like this as I want it to be as simple as possible
[14:01] <mvo> ogra_: interessting
[14:02] <rsalveti> mvo: right, that's indeed a concern (user space x kernel)
[14:03] <rsalveti> and as a user, what would you expect from a rollback?
[14:03] <mvo> would be all much more tidy if it was really kernel only and OS only
[14:03] <mvo> rsalveti: exactly!
[14:03] <ogra_> rsalveti, the exact same system i ran before the upgrade attempt
[14:03] <mvo> the current model is mentally much simpler
[14:04] <mvo> (maybe only because I'm lazy and haven't really thought through the new one of course :)
[14:04] <ogra_> but it doesnt keep kenerl and userspace distinct
[14:04] <ogra_> on the phone that would be fatal if we use a snappy base
[14:05] <ogra_> (we'd need one rootfs per device)
[14:06]  * mvo nods
[14:26] <Chipaca> mvo: question for you sir: what's the reasoning behind helpers.EnsureDir, as distinct from os.MkdirAll?
[14:26] <Chipaca> mvo: AFAICT the only difference is helpers.EnsureDir does not fail with error if the path exists and is not a directory
[14:27] <Chipaca> mvo: which I might argue is a bug, or an unfortunate name :)
[14:27] <mvo> Chipaca: laalalalalalalalala
[14:27] <Chipaca> mvo: noted.
[14:27] <mvo> Chipaca: is that enough of a answer ;) ? please kill it, its from my early go days when I did not realize that its legal to call MkdirAll() on exsiting dirs
[14:27]  * Chipaca aliases 'bzr laalalalalala' to 'bzr remove'
[14:28] <mvo> lol
[14:28] <Chipaca> mvo: so much pain in your early go days
[14:29] <mvo> Chipaca: not at all, I was just even more ignorant about the $world than today
[14:29] <mvo> Chipaca: fortunately I have people who clean up after me :)
[14:30] <Chipaca> mvo: who *claim* to clean up after you
[14:30] <mvo> :P
[14:31] <Chipaca> mvo: I would not have noticed, had it not being because in installClick we were using both helpers.EnsureDir and os.MkdirAll :)
[14:31] <Chipaca> s/being/been/
[14:32] <mvo> oh, both? meh, thats funny
[14:32] <davidcalle> jdstrand, I don't get the sentence at l9 & 10 of https://code.launchpad.net/~jdstrand/snappy/15.04-docs/+merge/260161 , are you sure about it or is it just my english failing me?
[14:33] <Chipaca> mvo: if that's funny, there's a lot of fun to be had :)
[14:33] <jdstrand> davidcalle: that could be rephrased better
[14:33] <jdstrand> davidcalle: let me do that
[14:35] <jdstrand> davidcalle: done
[14:37] <davidcalle> jdstrand, oh right, in the meantime I've figured out what "origin" is in that context, makes sense, thanks :)
[14:38] <Chipaca> mvo: is it legit that we're unpacking with dropped privileges, but then writing the click manifest with full privs?
[14:39] <Chipaca> mvo: and, followup question, would it be of the same or better legit-ness :) to write the click manifest from unpack? thus it happening with dropped privs automatically
[14:39]  * Chipaca thinking of moving writeCompatManifestJSON to clickdeb
[14:40] <mvo> Chipaca: I think that is a good idea and would improve things, yes
[14:40] <Chipaca> ok, i'll see if it works (i expect it to) :)
[14:44] <mvo> Chipaca: \o/
[14:44] <mvo> Chipaca: I envy you, I spend my day in recovery shells so far
[14:44]  * mvo takes a short break before the meeting ot get some $tea
[14:45]  * Chipaca ignores those pesky details such as "does it *actually* work, on a device" for now
[14:45] <davidcalle> jdstrand, merge acked
[14:51] <kyrofa> sergiusens, ping
[14:55] <Chipaca> ok, so, no, moving the click manifest creation to clickdeb is not workable at this point
[14:55] <Chipaca> reverting that (for now!)
[14:57] <sergiusens> kyrofa: pong
[14:57] <sergiusens> Chipaca: yeah, it requires major rework
[14:58] <Chipaca> sergiusens: i wouldn't say major, but as it's not the focus of this i'll postpone it for now
[14:58] <kyrofa> sergiusens, I've run into something interesting with the webdm API
[14:59] <kyrofa> sergiusens, I was hoping you could explain it?
[14:59] <sergiusens> kyrofa: sure; I bet it's just a bug :-P
[14:59] <kyrofa> sergiusens, haha! Well, let's see . . .
[15:00] <kyrofa> sergiusens, first of all, a question: The install API requires the package NAME as specified in the RFC, not the ID, right?
[15:01] <sergiusens> kyrofa: make me recall which one was the id and which one was the name
[15:02] <kyrofa> sergiusens, I called INSTALL xkcd-webserver, which got accepted. I then QUERYd xkcd-webserver and got "uninstalled." But if I query xkcd-webserver.canonical (its ID), it's "installed"
[15:02] <jdstrand> davidcalle: thanks!
[15:02] <sergiusens> kyrofa: ah, yes, always the id
[15:02] <kyrofa> Ah! Okay, for everything? (e.g. query, install, etc.)
[15:02] <sergiusens> kyrofa: it will allow installing but all refs would be lost; this is all due to legacy support in some sense
[15:03] <sergiusens> kyrofa: yes, always the id, the name is just for show
[15:03] <kyrofa> sergiusens, very good, okay. I suggest updating the RFC when you're able
[15:03] <kyrofa> sergiusens, thank you!
[15:03] <sergiusens> kyrofa: right, let me do that
[15:04] <davidcalle> jdstrand, and d.u.c updated. I now have a script that does most of the conversion and formatting work, so things should be faster in the future
[15:04] <jdstrand> sounds great
[15:25] <kyrofa> sergiusens, another difference between what I'm seeing and the RFC: calling INSTALL for a snap that's already installed still returns a 202, not a 200
[15:32] <sergiusens> kyrofa: yeah, we have that problem in snappy proper as well
[15:54] <Chipaca> mvo_: when is snappy in GOPATH? sergiusens?
[15:55] <Chipaca> i don't think it would ever be there, so i'm missing something
[15:55] <Chipaca> i mean the binary, to exec it
[16:02] <kyrofa> Chipaca, it doesn't need to be to exec it, right?
[16:02] <beowulf> mvo_: hey, thanks for the review, i don't have permission to top approve, would you mind also top approving? :) https://code.launchpad.net/~stephen-stewart/webdm/show-download-or-installed-size/+merge/260126
[16:02] <Chipaca> kyrofa: we look for it in PATH and GOPATH, hence my question
[16:04] <sergiusens> Chipaca: I think it's for snappy unpack and something mvo_ added to iterate faster
[16:05]  * Chipaca waits for mvo_ then
[16:06] <sergiusens> Chipaca: is it bothering you in some way?
[16:06] <Chipaca> sergiusens: well, it reimplements exec.LookPath
[16:06] <Chipaca> sergiusens: i was wondering whether we're doing that on purpose, or if it's code from early days :)
[16:07] <Chipaca> (the only difference between this and LookPath is GOPATH)
[16:07] <Chipaca> (and that LookPath is more careful with some error conditions)
[16:10] <sergiusens> Chipaca: oh, I care less about looking in GOPATH
[17:39] <sergiusens> Chipaca: ideas on this error? -> http://paste.ubuntu.com/11374504/
[17:51] <sergiusens> Chipaca: aparently solved by passing --use-existing-dir
[17:51] <sergiusens> mvo_: https://code.launchpad.net/~sergiusens/ubuntu-core-launcher/frameworkPathSupport/+merge/260189
[18:15] <mvo_> beowulf: sure, top approving now, sorry for the delay
[18:15] <mvo_> Chipaca: just to iterate faster on a real snappy its always in PATH not in GOPATH
[18:19] <beowulf> mvo_: ta
[18:22] <sergiusens> mvo_: what Chipaca implies is that it is rarely in GOPATH
[18:27] <mvo_> sergiusens: yeah, we can kill that lookup if its not needed
[18:31] <sergiusens> mvo_: where did ubuntu-core-config live again?
[18:31] <mvo_> sergiusens: bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/ubuntu-core-config/
[18:31] <sergiusens> mvo_: sounds good (allowing to remove code)
[18:31] <mvo_> sergiusens: lp:ubuntu/ubuntu-core-config I think or lp:ubuntu/wily/ubuntu-core-config
[18:31] <sergiusens> mvo_: thanks
[18:32] <mvo_> yw
[18:37] <sergiusens> mvo_: ubuntu branches are always hard to work with (personally), https://code.launchpad.net/~sergiusens/ubuntu/wily/ubuntu-core-config/frameworks-writable/+merge/260200
[18:43] <sergiusens> mvo_: and maybe https://code.launchpad.net/~sergiusens/ubuntu/wily/ubuntu-core-config/azure-datasource/+merge/260201
[18:45] <mvo_> sergiusens: looks good, I can merge/upload tomorrow morning
[18:45] <sergiusens> mvo_: sure, no hurry
[20:10] <kgunn> mterry: so i downloaded virtual machine manager cause i wanna be like mike :)
[20:10] <mterry> kgunn, right, it was very easy to set up for me
[20:10] <kgunn> ok...getting thru that now
[20:11] <kgunn> mterry: complains about libvirt
[20:12] <mterry> kgunn, when installing via apt-get?
[20:12] <kgunn> mterry: i used sw store...
[20:12] <mterry> sure
[20:12] <mterry> kgunn, what was the error?
[20:13] <kgunn> mterry: when it starts, just a dialog "Unable to connect to libvirt" so i should verify
[20:13] <kgunn> that i have libvirt-bin installed, i do
[20:13] <mterry> huh
[20:13] <kgunn> The 'libvirtd' daemon has been started
[20:13] <mterry> i didn't see that at all
[20:14] <kgunn> mterry: ok...let me dork with it a bit
[20:14] <kgunn> it's got some more details
[20:14] <kgunn> i can try some stuff
[20:58] <Chipaca> gah, missed mvo
[20:58] <Chipaca> my question was *when* is snappy in GOPATH and not in PATH
[21:07] <sergiusens> Chipaca: when testing, but he said you can remove
[21:16] <kgunn> mterry: hehe, so apparently a reboot helped :)...so when you created your vm in vmm, do you recall what you picked for "OS type" and "version"
[21:16] <mterry> kgunn, that's dumb.  :-/
[21:16] <kgunn> i left generic...but then it warned "for better performance, pick an OS"
[21:17] <mterry> kgunn, I think I left that blank, yeah
[21:17] <kgunn> k
[21:17] <mterry> kgunn, you know how to get a recent snappy image?
[21:18] <kgunn> mterry: so i was just following instructions from here
[21:18] <kgunn> https://developer.ubuntu.com/en/snappy/start/
[21:18] <kgunn> so i got a 15.04 image
[21:19] <mterry> kgunn, sure should be fine
[21:38] <kgunn> mterry: sorry keep getting distracted, but is your work flow to create a vm within wmm ? or do launch outside and just connect to it?
[21:38] <kgunn> just realizing vmm changes img group/owner
[21:38] <mterry> kgunn, I make the .img file on my own.  Then inside WMM I add it?  Like going through that dialog that asked you for "OS type"
[21:39] <kgunn> ok...that's what i did mterry, but then it when launched it says
[21:40] <kgunn> failed to boot, no such device
[21:40] <kgunn> arggg why is my connection being a dog all of the sudden
[21:40] <mterry> kgunn, :(
[21:41] <mterry> failed to boot...
[21:41] <mterry> kgunn, and you pointed your new VM at the .img file during setup?
[21:42] <kgunn> yep lemme grab a pic
[21:46] <kgunn> mterry: https://drive.google.com/a/canonical.com/file/d/0B4GvOYxwuvpFQVNvbmdnTVZaVVk/view?usp=sharing
[21:47] <mterry> kgunn, when you made your VM, you chose "import existing disk image" in the first dialog?
[21:48] <kgunn> mterry: oh...nope, i chose "local install"
[21:48] <kgunn> so i goofed
[21:48] <mterry> kgunn, eh, it's a weird dialog
[21:48] <mterry> kgunn, but yeah, try again with existing disk
[21:50] <kgunn> there we go
[21:50] <kgunn> thanks mterry
[21:50] <kgunn> ...back to fiddling
[21:50] <mterry> kgunn, awesome
[23:02] <kgunn> mterry: hey, the first part of your instructions, do you just do this to verify it's sane
[23:02] <kgunn>  open VM
[23:02] <kgunn>  ssh ubuntu@192.168.122.69
[23:02] <kgunn>  ls
[23:02] <kgunn>  snappy list
[23:02] <kgunn> i'm building snappy-packaging....btw :D
[23:02] <mterry> yeah
[23:02] <mterry> Just to prove the VM is clean
[23:03] <kgunn> ...and failed to build...dang it...
[23:04] <kgunn> ah needs gfx drivers