[06:28] <dholbach> good morning
[07:02] <fgimenez> good morning
[07:16] <mvo> hey fgimenez, good morning
[07:16] <mvo> ogra2: hi, around?
[07:16] <mvo> or ogra_
[07:18] <fgimenez> hey mvo
[07:20] <mvo> fgimenez: could you please add a card that we add  a integration test that basicly checks for "systemctl status | grep State: degraded"? It looks like opencryptoki is failing right now
[07:20] <mvo> hey dholbach, good morning!
[07:20] <mvo> dholbach: are you at ubucon already?
[07:20] <mvo> dholbach: did you guys had a great release party?
[07:20] <dholbach> mvo, nope - it's starting tomorrow
[07:20] <mvo> aha, ok
[07:20] <dholbach> mvo, there's a social event tonight though
[07:21]  * mvo nods
[07:21] <dholbach> so there'll be time for everyone to have some of their favourite beverages
[07:21] <mvo> sounds like a lot of fun
[07:21] <fgimenez> mvo, sure! :) we have already some tests that query systemctl status, should we be waiting/polling for that condition?
[07:22] <mvo> fgimenez: well, we want to make sure that it does not boot into this degraded mode, i.e. that no unit fails :) pardon my ignorance on how the integration test for systemctl status works right now, I would (naively) assume that after you waited for boot-ok and before rebooting would be a good time to check that no unit failed
[07:24] <fgimenez> mvo, indeed, currently we ask systemctl for status of restarted services, for instance, in which case makes sense to wait for the service to be up. As you say after booting we can assert that all the units are ok
[07:25] <mvo> fgimenez: great, thanks a bunch
[08:04] <davidcalle> morning o/
[08:55] <Chipaca> mvo: hoe gaat het?
[08:56] <JamesTait> Good morning all; happy Friday, and happy Mole Day! 😃
[08:56] <Chipaca> JamesTait: also happy UN day!
[08:57] <JamesTait> Chipaca, do they make holes in your lawn as well?
[08:57] <Chipaca> JamesTait: I'm not sure. Bosnia made me think they do.
[08:58] <Chipaca> JamesTait: but that might have been all the other guys doing the holes and UN trying to fill them
[08:58] <mvo> Chipaca: hey, not too bad, one glitch in the release with opencryptoki, otherwise all good
[08:58] <mvo> Chipaca: how are you?
[08:59] <Chipaca> mvo: relaxed :)
[08:59] <Chipaca> perhaps prematurely :D
[08:59] <mvo> great!
[08:59] <mvo> no, all good
[09:00] <ogra_> mvo, on my way out ... whats up ?
[09:00] <mvo> ogra_: I was wondering how important opencryptoki is
[09:00] <mvo> ogra_: but no worries, drive, I have it all under control
[09:00] <ogra_> it was part of the reqs for the encryption
[09:01]  * mvo nods
[09:01] <ogra_> you gotta ask ricmm
[09:20] <dholbach> mvo, snapcraft is just used for app snaps, right?
[09:20] <dholbach> so documenting meta/package.yaml for let's say gadget snaps still makes sense
[09:21] <mvo> dholbach: it does, yes. long term this may change though
[09:22] <dholbach> ok, thanks
[11:29]  * Chipaca goes for lunch
[13:16] <tedg> dholbach: I think that it is being used for the Mir framework snap
[13:16] <tedg> dholbach: It doesn't provide any help there, but also won't get in the way.
[13:17] <dholbach> tedg, hum...
[13:17] <dholbach> tedg, I can't quite remember what you're referring to right now O:-)
[13:21] <tedg> dholbach: Sorry, didn't read the timestamps, just the last few messages :-)
[13:21] <tedg> dholbach: About snapcraft only doing app snaps.
[13:22] <dholbach> oh ok
[13:22] <dholbach> thanks
[14:07] <dholbach> do we have any docs on how to sign snaps or is this something we say just the store does?
[14:15] <elopio> fgimenez: there was already a card for that: https://trello.com/c/kyipW838/260-add-a-test-to-check-that-no-service-failed-to-load
[14:15] <elopio> we can just drop this one and keep the new one.
[14:17] <fgimenez> elopio, sorry didn't know. ok, we can keep any of them, the check proposed by mvo would catch any service not being loaded
[14:19] <elopio> fgimenez: and we are upstream, finally \o/ https://github.com/testing-cabal/subunit-go
[14:20] <fgimenez> elopio, great! \o/
[14:20] <elopio> now that niemeyer is working with us, it might be easier to get better integration with go check.
[14:23] <fgimenez> elopio, i've archived the new card about the services and added a comment with the check to the existing one
[14:27] <elopio> fgimenez: ok. And about scalignstack, we were sooo close, but now we are back to convincing people why we need them :(
[14:32] <fgimenez> elopio, yep, i've seen, some day maybe... :) it seems that we are back to square one, but they haven't responded yet to your last email, let's see
[14:45] <noise][1> where can I find the source for the pi2 snap from http://people.canonical.com/~platform/snappy/raspberrypi2/ ?
[14:47] <noise][1> ogra_: you were building these images right?
[15:48] <elopio> noise][1: ogra is travelling to a conference today. If you only need the source, just open the snap with file-roller.
[15:48] <elopio> or do you need to do something in the repository?
[15:49] <noise][1> elopio: did that, but then found that the package.yaml doesn't include webdm and now i'm wondering precisely how those images are rolled
[15:49] <noise][1> basically I want to be able to duplicate the released image so I know i'm starting from a good place, then make some mods
[15:51] <elopio> noise][1: like this? https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/
[15:51] <elopio> udf takes all the snaps, and combines them. You can pass a local snap in --oem.
[15:52] <elopio> udf takes all the snaps, and combines them. You can pass a local snap in --oem.d0n_pa!a\/ra*
[15:52] <dholbach> all right my friends - I call it a day - see you all on Monday!
[15:53] <elopio> bye dholbach. Enjoy the weekend.
[15:53] <dholbach> you too
[15:53] <dholbach> still need to prepare my demo for Ubucon DE :)
[15:54] <dholbach> see you :)
[15:55] <noise][1> elopio: that page just isn't clear exactly what is used to create the images because they have webdm but it's not part of the oem snap, so I'm assuming it's done via u-d-f's —install webdm.canonical, but wanted to get confirmation of that
[15:56] <elopio> noise][1: I suppose you are right, but can't confirm.
[15:57] <noise][1> when i tried that, webdm didn't seem to start, but i'm still working through this so it's quite possible i just did something wrong
[16:45] <jdstrand> hmm
[16:46] <jdstrand> Chipaca: hey, I see bug #1498842. I just uploaded snappy-debug 0.3 to the store and snappy update isn't detected it. I had 0.2 installed. snappy-debug has a store alias of 'snappy-debug'
[16:46] <jdstrand> Chipaca: so it seems I am seeing the inverse of that bug. ie, a package with an alias isn't updating
[16:47] <jdstrand> Chipaca: seeing this on stable r9 and edge r229. file a bug?
[16:48] <Chipaca> jdstrand: try again?
[16:50] <jdstrand> Chipaca: I tried 5 times
[16:51] <Chipaca> echo '{"name":["snappy-debug.canonical"]}' | POST -H 'Accept: application/json' -H 'X-Ubuntu-Frameworks: ubuntu-core-15.04-dev1' -H 'X-Ubuntu-Architecture: amd64' -H 'X-Ubuntu-Release: 15.04-core' 'https://search.apps.ubuntu.com/api/v1/click-metadata'|jq .
[16:51] <Chipaca> jdstrand: ^ that's what snappy does
[16:51] <jdstrand> snappy search sees it and I can install it
[16:51] <Chipaca> jdstrand: I see 0.3 here
[16:51] <jdstrand> yes
[16:51] <jdstrand> so do I
[16:51] <jdstrand> but snappy update doesn't install it
[16:51] <jdstrand> I can search it fine, I can install it fine, it won't update
[16:52] <jdstrand> $ snappy list|grep debug
[16:52] <jdstrand> snappy-debug  2015-10-19 0.2          canonical
[16:52] <jdstrand> $ sudo snappy update
[16:52] <jdstrand> $
[16:52] <jdstrand> $ snappy list|grep debug
[16:52] <jdstrand> snappy-debug  2015-10-19 0.2          canonical
[16:52] <Chipaca> jdstrand: snappy list -u ?
[16:53] <jdstrand> $ snappy search snappy-debug|grep debug
[16:53] <jdstrand> snappy-debug          0.3                snappy-debug
[16:53] <jdstrand> ~$ snappy list -u
[16:53] <jdstrand> Name          Date       Version
[16:53] <jdstrand> ubuntu-core   2015-10-23 9
[16:53] <jdstrand> hello-world   2015-10-01 1.0.18
[16:53] <jdstrand> minecraft     2015-10-10 0.4
[16:53] <jdstrand> snappy-debug  2015-10-19 0.2
[16:53] <jdstrand> ufw           2015-10-12 IDDaHcdMFHdS
[16:53] <jdstrand> generic-amd64 2015-09-30 1.4
[16:55] <Chipaca> nessita or matiasb, you guys around?
[16:56] <jdstrand> Chipaca: just for perfect clarity-- snappy-debug has a store alias
[16:56] <Chipaca> jdstrand: and it's a framework
[16:56] <jdstrand> no, it isn't
[16:56] <Chipaca> jdstrand: ok
[16:56] <nessita> yes
[16:56] <Chipaca> nessita: hola! Can i pester you with a question about cpi?
[16:57] <nessita> of course
[16:57] <jdstrand> Chipaca: it started as one, but we changed that. 0.2 was not a framework and neither is 0.3
[16:57] <Chipaca> nessita: jdstrand has a snap at version 0.2, published 0.3, but snappy update can't find it
[16:57] <Chipaca> nessita: but
[16:57] <Chipaca> nessita: the url snappy update hits returns 0.3
[16:58] <Chipaca> nessita: so i'm missing something :-/
[16:58] <nessita> Chipaca, let me check the store data
[16:59] <Chipaca> nessita: thanks
[16:59] <nessita> Chipaca, snappy-debugis the package name?
[16:59] <Chipaca> nessita: .canonical
[16:59] <nessita> from myapps 0.3 should be published in every channel, debugging further
[17:01] <nessita> Chipaca, what would mean "snappy can't find it"? I see the metadata OK (https://search.apps.ubuntu.com/api/v1/package/snappy-debug.canonical) perhaps you can't download?
[17:02] <Chipaca> nessita: well, search works and finds 0.3, so i assume it's not that
[17:02] <Chipaca> nessita: if nothing jumps out at you, never mind
[17:02] <Chipaca> i'll dig into this later
[17:02] <Chipaca> jdstrand: bug time!
[17:02] <nessita> Chipaca, what is weird is that browsing https://public.apps.ubuntu.com/download/canonical/snappy-debug.canonical/snappy-debug.canonical_0.3_all.snap I get nothing
[17:02] <nessita> Chipaca, so let me check our package storage status
[17:03] <Chipaca> jdstrand: hold off on the bug :)
[17:04] <nessita> Chipaca, so https://public.apps.ubuntu.com/download/canonical/snappy-debug.canonical/snappy-debug.canonical_0.3_all.snap is giving 401
[17:04] <nessita> Chipaca, so it requires auth, so somehow is not matching criteria for "allow unathenticated". Let me dig more.
[17:04] <Chipaca> jdstrand: you haven't paid your store subscription! I'll transfer you to accounts. Please hold.
[17:06] <nessita> Chipaca, in any case, while I debug, the snappy install should check return codes when downloading a package, to help debugging
[17:07] <nessita> (and do retries on network errors)
[17:07] <nessita> just mentioning in case you can build ToDos
[17:09] <Chipaca> nessita: looking at the code i'd tell you it does report errors
[17:10] <Chipaca> so if this is because a 401, somehting's awry
[17:10] <Chipaca> but it's not even that
[17:10] <Chipaca> because it'd print "Updating <package>..."
[17:10] <Chipaca> but it's not even getting that far
[17:11] <nessita> Chipaca, any chance you can try to pin point where is failing in that end?
[17:12] <Chipaca> the only thing i can see where it would fail silently like this
[17:12] <Chipaca> is if the store is returning json that doesn't fit into the expected struct
[17:13] <nessita> Chipaca, ok, so enigma solved for the 401, we need to use the anon URL
[17:13] <nessita> Chipaca, so I would say nothing stands out in our end
[17:14] <Chipaca> nessita: thanks
[17:17] <nessita> Chipaca, let me know if you can detect the exact point of failure to debug our end
[17:17] <Chipaca> jdstrand: file a bug, i'll dig on monday
[17:18] <jdstrand> Chipaca: ok
[17:24] <jdstrand> Chipaca: https://bugs.launchpad.net/snappy/+bug/1509451
[17:27] <Chipaca> umm
[17:27] <Chipaca> jdstrand: it just udpated for me, fwiw
[17:27] <Chipaca> so.
[17:27] <Chipaca> augh
[17:27]  * Chipaca should leave
[17:28] <Chipaca> jdstrand: i installed a fake 0.2, and snappy updated it to 0.3
[17:28] <Chipaca> jdstrand: is this a vm?
[17:29] <Chipaca> jdstrand: if it is, please preserve the disc image
[17:30] <jdstrand> Chipaca: it isn't a test vm
[17:30] <Chipaca> jdstrand: any chance you can make an image of the disc?
[17:32] <Chipaca> for monday
[17:32] <Chipaca> i'm out
[17:32] <Chipaca> o/
[17:33] <jdstrand> Chipaca: well, not trivially. ping me on monday and we'll work something out