=== joc|away is now known as joc_
ogra_kyrofa, hmm, did you see the softpedia article about your blog post ?08:57
ogra_..."Now, the good news we want to share with you today is that the guys over at Canonical managed to implement support for the I2C communications protocol and General-purpose input/output (GPIO) on the Raspberry Pi 2 device for Ubuntu Core.09:00
ogra_Therefore, the Snappy Scope has now extra functionality, such as support for listing installed and stored snaps (.snap packages), as well as support for installing and uninstalling snaps."...09:00
* ogra_ wonders why the scope needs GPIO when reading these lines ... :P09:01
ogra_http://news.softpedia.com/news/ubuntu-core-receives-support-for-gpio-and-i2c-on-the-raspberry-pi-2-video-489854.shtml for reference btw09:12
zygahey, I was using snapcraft run to test my snap09:38
zygabut it failed to install in a way I don't understand:09:39
zyga2015/08/24 09:28:44 Signature check failed, but installing anyway as requested09:39
zygano config found for this snap09:39
zygathe "no config found for this snap" is the last thing I get before the install command fails (snappy install on the device)09:39
zygaany ideas what that means?09:39
Chipacazyga: strange, can you pastebin the whole thing from the command you use to install on?09:46
zygaChipaca: yep09:47
zygaChipaca: http://pastebin.ubuntu.com/12182344/09:47
zygaChipaca: it's not the full log but it's pretty boring at the top09:48
zygaChipaca: I can give you the snap if you want09:48
Chipacazyga: please09:49
mvozyga: anything special in the snap, i.e. does it actually have a config handler09:49
mvohey Chipaca good morning09:49
zygamvo: not that I can think09:49
zygaI'll show you the snapcraft yaml09:49
Chipacazyga: do you have any other *.snap other than the one you were expecting to have?09:49
* Chipaca grumbles about snapcraft doing "scp *.snap"09:50
zygaChipaca: I fixed a lot of bugs in snapcraft but I realized this is still using *.snap there09:50
Chipacamvo: good morning sah!09:50
zygaChipaca: so is this more like an update issue?09:50
zygaor is it related to the new snap09:50
Chipacazyga: I don't know. Can you put the actual generated snap somewhere?09:51
zygaChipaca: yep, copying to chinstrap, to ~zyga09:51
zygaChipaca: it's a private snap so please don't share it09:51
zygaChipaca: ETA ~2m09:51
Chipacazyga: ok, ta09:52
zygaChipaca: done, can you get it from chinstrap?09:57
Chipacaa ver...?09:57
Chipacazyga: yep09:58
Chipacazyga: it works here09:59
zygaChipaca: weird09:59
Chipacazyga: can you check whether it's installing and then trying to run config on it?09:59
Chipacazyga: e.g., install it by hand09:59
Chipacazyga: because what it looks like is that the install is succeeding, and then snapcraft tries to do "snappy config", which fails10:00
Chipacabut the command that is in the traceback does not support that10:00
zygaChipaca: please refresh my memory, what is snappy config?10:00
Chipacaso a possibility is that there's a broken try/except that's masking the proper command10:00
Chipacazyga: a way for snaps to be configured10:00
Chipacazyga: but it's separate from installation10:00
Chipacazyga: you'd run 'sudo snappy config package < configfile' and the config file would be passed to a config hook in your package10:01
Chipacazyga: (idea is to at some point have a schema so a config interface can be created automagically)10:01
zygaChipaca: I don't have any hooks myself, where are hooks specified? are they per par or on the whole snap?10:02
Chipacazyga: i could answer that question, but i believe you are misunderstanding what i think the problem is10:02
Chipacazyga: your snap has no config10:03
Chipacazyga: no config hook10:03
Chipacazyga: so running "snappy config" will fail, with exactly the error you print10:03
Chipacazyga: "snappy install" does not run "snappy config"10:03
Chipacazyga: so it's possible snapcraft is running config after install itself10:03
zygahmm, odd, is it?10:04
Chipacazyga: you could confirm this if you did "snappy install" yourself, manually instead of through snapcraft10:04
zygaChipaca: I read the code just now, it's not doing snappy config10:04
zygaChipaca: it's only doing sudo snappy install *.snap10:04
Chipacait's the *.snap thing!10:05
Chipaca  snappy [OPTIONS] install [install-OPTIONS] [package name] [config file]10:05
zygaChipaca: I have a patch for that section but I did not change the meaning really10:06
zygaChipaca: I'll fix that localyl10:06
zygaChipaca: and send you MRs10:06
Chipacazyga: i hope that was a plural you :) 'cause i'm not on snapcraft right now10:06
zygaI didn't know that10:06
zygaI'll just send it to lp:snapcraft, I'm sure someone can be poked into reviewing and landing them10:06
Chipacazyga: thanks :)10:08
mvoogra_: how is the uboot.env stuff is looking? any issues so far? or did we finally kill the corruption issues?10:24
* mvo is catching up on the last weeks10:24
ogra_mvo, all fine and stable10:24
ogra_no issues so far10:24
ogra_(at least i havent heard anything in that direction)10:24
ogra_documentation updates are missing ... for the porting doc10:24
mvoogra_: thanks, that sounds like (hopefully) something straightforward10:26
ogra_kind of, yeah :)10:27
=== Laney is now known as Guest65212
=== ubott2 is now known as ubottu
=== Guest65212 is now known as Laney
* Chipaca ~> the search of the lost lunch11:12
* ogra_ hands Chipaca a faded map with a dotted line and cross on it 11:13
davmor2Chipaca: the map is a lie, it's to pirate treasure, you'll starve before you get there and ogra_ will eat your food cause he's like that ;)11:22
mvoChipaca: could you please set the prereq branch to schmideload in the service-endisable branch? so that the diff is easier to read :)11:36
ogra_mvo, wrt bug 1479711 ... do you think we should backport it to 15.04 ?11:57
ubottubug 1479711 in initramfs-tools-ubuntu-core (Ubuntu) "snappy should not mount with "discard" option" [Undecided,New] https://launchpad.net/bugs/147971111:57
* ogra_ just uploaded the change to wily11:57
mvoogra_: probably yes11:59
ogra_ok, i'll shelve it until i hear back from ricmm_ about the resize tests on 15.0411:59
ogra_(dont want to taint the testing right now)12:00
ogra_hmm, we have 132 open bugs ... and only 33 of them are triaged at all, the rest is in undecided state12:09
ogra_pitti, do you happen to have any hint for bug 1485683 ? smells like an ordering prob of the units or some such12:11
ubottubug 1485683 in Snappy "/etc/sysctl.d is not applied on boot" [Undecided,New] https://launchpad.net/bugs/148568312:11
kyrofaogra_, eh? No!12:24
pittiogra_: replied12:43
kyrofaogra_, haha, read the article. Thanks for the reference! Indeed, not sure how informed the author was, but it's good press anyway :)12:45
kyrofaogra_, and they were obviously thrilled with your work!12:47
ogra_pitti, ah, cool ... though i wonder if we should perhaps move the sysctl stuff out of systemd in this case ... we might want values to be set before mounting for example12:48
ogra_i guess there is a reason why it usually runs early12:48
ogra_yeah, but it make one wonder why the snap scope needs I2C to work :)12:48
kyrofaogra_, yeah, my fault for writing about both in the same article :P12:49
ogra_yeah, two topics in the same article is to much for some :)12:49
kyrofaogra_, haha, I'll keep that in mind12:53
ogra_wow, searching for snapcraft gets me a ton of minecraft posts on google13:41
ogra_the actual howto is the pre-last hit13:41
* ogra_ curses finger memory13:44
ogra_ogra@anubis:~$ sudo snappy install snapcraft13:44
ogra_Installing snapcraft13:44
ogra_snapcraft failed to install: snappy package not found13:44
=== davidcalle_ is now known as davidcalle
longsleepChipaca: do you have an opinion on bug #1484641 - does one need to implement restart logic in the snap or should that be done automatically? I am also wondering on when/if the config hook is run on installation.13:57
nothalBug #1484641: snappy config command does not restart service after setting the configuration <Snappy:New> <http://launchpad.net/bugs/1484641>13:57
ubottubug 1484641 in Snappy "snappy config command does not restart service after setting the configuration" [Undecided,New] https://launchpad.net/bugs/148464113:57
Chipacalongsleep: the config hook is run on install if you give it a config argument13:57
ogra_snapcraft downloading is unbelivable noisy13:58
longsleepChipaca: config argument like snappy install mysnap --config ?13:58
Chipacalongsleep: i don't have an opinion as to whether a service should be restarted on config; wouldn't the config hook know whether it needs to do this or not?13:58
longsleepChipaca: yes it would, though the docs say that the systemd service is restarted13:58
longsleepChipaca: and that is the usual thing to do, and i think that cannot be done from the config hook can it?13:59
Chipaca  snappy [OPTIONS] install [install-OPTIONS] [package name] [config file]13:59
Chipacalongsleep: (from snappy install --help)13:59
Chipacainterestingly, that does not appear in the manpage that's generated from the same information14:00
Chipacasilly go-flags14:00
longsleepChipaca: ok thats one way to do it, what about the configuration specified in the oem snap, do you know then this is applied. I mean if my oem snap provides config for a snap, does this get applied when the snap is installed later?14:01
Chipacalongsleep: i don't remember offhand, but i can look14:02
Chipacagive me a sec14:02
longsleepcool thanks14:02
Chipacalongsleep: it looks like it's applied on first boot14:03
longsleepChipaca: ok, well i think that is good enough for my purpose then. Where i pre populate various snap configs.14:05
rickspencer3can anyone tell me what I am doing wrong here?14:06
rickspencer3(BeagleBoneBlack)ubuntu@localhost:~$ sudo snappy update14:06
rickspencer3another snappy is running, try again later14:06
* rickspencer3 braces14:07
rickspencer3ogra_, I assume I did something very silly?14:07
ogra_no idea, i have never seen that :)14:07
mvorickspencer3: nothing wrong, there is probably (90% confidence) just snappy autopilot running in the background and updating you14:07
mvorickspencer3: its doing that automatically every couple of hours14:08
rickspencer3mvo, so, I just plugged it in for the first time in weeks, I guess it triggered then?14:08
rickspencer3so, I just wait?14:08
mvoI guess we need to improve the error message or (even nicer) "attach" to the running snappy so that you can see what its doing14:08
rickspencer3I guess I will get kicked out of my ssh session when it is done and reboots?14:09
mvorickspencer3: yeah, just wait and/or check /var/log/syslog, iirc it prints some progress there14:09
longsleeptry something like `ps ax|grep snappy`14:09
rickspencer3mvo, would you like me to log a bug?14:09
mvorickspencer3: it will inform you about the reboot and give you a chance to cancel it14:09
mvorickspencer3: yeah, please do14:09
ogra_mvo, we should make the message more clear14:11
longsleepwhoohoo mvo is processing all my bugs /cheer !!14:13
rickspencer3mvo, enjoy bug #148811414:13
nothalBug #1488114: Confusing message while manually updating during an automatic update <Snappy:New> <http://launchpad.net/bugs/1488114>14:13
* rickspencer3 is going to try to make an led light up with snappy :)14:13
ogra_rickspencer3, whee, like edison !!!14:14
rickspencer3mvo, oh nice, I see it gives me 10 minutes before the automatic reboot14:15
mvorickspencer3: yeah and it should also tell you how to cancel it14:18
rickspencer3yeah, it's all very clear and nice14:19
rickspencer3ogra_, does this diagram mean that P8_8 is a digital write pin? https://www.safaribooksonline.com/library/view/programming-the-beaglebone/9780071832120/images/figc-1.jpg14:23
rickspencer3i.e. if I want to send 5v to a breadboard, I use a jumper from one of those pins?14:24
ogra_uh, no idea, sorry ... and that diagram doesnt really say anything14:24
ogra_(apart from telling you where P8_8 sits)14:24
rickspencer3oh weird, it made the led glow slightly!14:24
rickspencer3ogra_, maybe this one is better?14:25
rickspencer3looks like it is GPIO_67 ?14:25
ogra_rickspencer3, yeah, looks like you should be able to switch it by using GPIO_6714:26
beunorickspencer3, http://beagleboard.org/static/images/cape-headers-digital.png14:26
beunoI use that14:26
* rickspencer3 looks14:26
ogra_well, pretty much the same14:26
beunoI guess it's the same, but has the nice colors to distinguish14:26
beunobut you get red for electrical stuff!14:27
rickspencer3so, weird that it completed the circuit before I wrote any code!14:27
rickspencer3I guess when the GPIO pin is unitialized, it sends it electricity ;)14:28
rickspencer3now it's time to get control ;)14:28
imuguruzaanyone using Snappy in OdroidC1??14:30
ogra_imuguruza, longsleep does14:31
imuguruzagreat, I just realized I have downloaded his img14:32
imuguruzalongsleep: any chance of using I2C?14:32
imuguruzaI have installed i2c-tools but can't open it14:33
longsleepimuguruza: you might have to load some modules15:02
longsleepimuguruza: i am using SPI with no problems, did not try I2C for a while15:02
imuguruzaI'm interested on SPI also15:03
longsleepwell for spi you just load spicc and spidev module15:03
longsleepmodprobe spicc15:03
longsleepmodprobe spidev15:03
longsleepthen you have /dev/spi.. and can use the examples from the linux kernel15:04
longsleepimuguruza: also the snappy image kernel has the same gear as the hardkernel kernel, so anything you try on normal Ubuntu should work on Snappy as well.15:05
longsleepah yes15:05
longsleepmodprobe aml_i2c15:05
longsleepshould give you the i2c bus15:05
imuguruzalongsleep: yes!15:06
imuguruzagreat, thanks!15:06
longsleepimuguruza: you are welcome15:07
elopioogra_: when you sy boottest, do you mean something like this? http://bazaar.launchpad.net/~canonical-ci-engineering/ubuntu-touch-boottest/trunk/view/head:/tests/boottest/debian/tests/boottest15:24
ogra_elopio, well, boot a VM with a new initrd and see if it comes up at all would be my first test15:25
ogra_then as a next step go through the initrd code and look what it does ... wherever applicable add a test to check that it did what it was supposed to do for each individual bit15:26
elopioogra_: we already kind of have that. If the vm doesn't get an ip, the integration tests would fail.15:26
ogra_well, in the specific case of the resize script you would check if after first boot there is more then 10% unpatitioned spasce on the disk your writable partition lives on15:27
ogra_that would indicate that it failed to run15:27
elopiothat we can easily add, sure. Let me start there.15:28
ogra_where we can test such stuff from the normal initrd bits we should do that as well15:28
ogra_many bits are hidden sadly ... like mounting ... since usually the last step is to move-mount the bits and pieces15:29
ogra_so the running system wouldnt see the initial mount or if there were failures ...15:29
ogra_such bits we cant really test15:29
elopioogra_: there must be a way, but probably we will have to build it. Something that listens to the events that happen during that script, and record them.15:31
ogra_well, that would mean you test a hacked version of the initrd15:31
elopioif it's too hard, it might not be worth it to automate and we can just crowd test it.15:31
ogra_not sure how reliable we consider that15:31
ogra_we could add more logging all over the place though ... and you could at least parse that log from /dev/initramfs/15:32
elopioogra_: as with everything we test, the idea is to catch some of the possible bugs, not all of them. Ideally the most important ones. And if we consider the impact of those bugs to be more expensive than to write the tests, then we automate the tests even if parts are faked.15:34
elopioogra_: I think you could add at least one log message so we can easily check that the script ran.15:34
elopioif you add many more messages, that would affect the boot time, right?15:35
ogra_it would just be some echos and redirects15:36
ogra_shouldnt impact the boot time much15:36
ogra_if something seriously went wrong with the default script you most likely wont finish booting anyway15:36
ogra_the log would just be a finer grained view of what the general boot process did15:37
elopioogra_: ok. So for testing, we need only one log message per branch. If you don't have any ifs, it's the same to have one log at the end or many logs.15:37
elopiobut for debugging, more logs will help.15:37
=== Michaela is now known as Mikaela
rsalvetielopio: ogra_: we might also be able to mock some of the core pieces of the initrd code, and test that when building the package15:48
rsalvetibesides checking for logs after the system booted15:49
rsalvetibut yeah, as elopio said, need to check for the complexity15:49
elopioand I insist that running the script standalone in an already booted system gives some value.15:49
elopionot a lot, but it will discover some obvious problems.15:49
elopioso during the boot, we can ignore those obvious problems and test for other things.15:50
mcphailAre there any resources/guides detailing best practice, caveats and gotchas for snappificating an existing package? I was wondering whether it would be helpful to have a cohort of "case studies" of existing packages to highlight these. Perhaps it would be useful for both package builders and snappy devs?16:21
longsleepmcphail: Take a look at https://developer.ubuntu.com/en/snappy/snapcraft/16:26
mcphaillongsleep: that's not quite what I meant. I'm thinking more of focusing on the thing snappy doesn't handle well/easily such as man pages, bash completion etc16:29
=== sarnold_ is now known as sarnold

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!