| === 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 ... :P | 09:01 | |
| svij | experts! | 09:02 |
| ogra_ | http://news.softpedia.com/news/ubuntu-core-receives-support-for-gpio-and-i2c-on-the-raspberry-pi-2-video-489854.shtml for reference btw | 09:12 |
| zyga | hey, I was using snapcraft run to test my snap | 09:38 |
| zyga | but it failed to install in a way I don't understand: | 09:39 |
| zyga | 2015/08/24 09:28:44 Signature check failed, but installing anyway as requested | 09:39 |
| zyga | no config found for this snap | 09:39 |
| zyga | the "no config found for this snap" is the last thing I get before the install command fails (snappy install on the device) | 09:39 |
| zyga | any ideas what that means? | 09:39 |
| Chipaca | zyga: strange, can you pastebin the whole thing from the command you use to install on? | 09:46 |
| zyga | Chipaca: yep | 09:47 |
| zyga | Chipaca: http://pastebin.ubuntu.com/12182344/ | 09:47 |
| zyga | Chipaca: it's not the full log but it's pretty boring at the top | 09:48 |
| zyga | Chipaca: I can give you the snap if you want | 09:48 |
| Chipaca | zyga: please | 09:49 |
| mvo | zyga: anything special in the snap, i.e. does it actually have a config handler | 09:49 |
| mvo | hey Chipaca good morning | 09:49 |
| zyga | mvo: not that I can think | 09:49 |
| zyga | I'll show you the snapcraft yaml | 09:49 |
| Chipaca | zyga: do you have any other *.snap other than the one you were expecting to have? | 09:49 |
| zyga | http://paste.ubuntu.com/12182360/ | 09:49 |
| zyga | ohh | 09:49 |
| * Chipaca grumbles about snapcraft doing "scp *.snap" | 09:50 | |
| zyga | yes | 09:50 |
| zyga | yes | 09:50 |
| zyga | thanks | 09:50 |
| zyga | Chipaca: I fixed a lot of bugs in snapcraft but I realized this is still using *.snap there | 09:50 |
| Chipaca | mvo: good morning sah! | 09:50 |
| zyga | Chipaca: so is this more like an update issue? | 09:50 |
| zyga | or is it related to the new snap | 09:50 |
| Chipaca | zyga: I don't know. Can you put the actual generated snap somewhere? | 09:51 |
| zyga | Chipaca: yep, copying to chinstrap, to ~zyga | 09:51 |
| zyga | Chipaca: it's a private snap so please don't share it | 09:51 |
| zyga | Chipaca: ETA ~2m | 09:51 |
| Chipaca | zyga: ok, ta | 09:52 |
| zyga | Chipaca: done, can you get it from chinstrap? | 09:57 |
| Chipaca | a ver...? | 09:57 |
| Chipaca | zyga: yep | 09:58 |
| Chipaca | done | 09:58 |
| Chipaca | aha | 09:59 |
| Chipaca | zyga: it works here | 09:59 |
| zyga | Chipaca: weird | 09:59 |
| Chipaca | zyga: can you check whether it's installing and then trying to run config on it? | 09:59 |
| Chipaca | zyga: e.g., install it by hand | 09:59 |
| Chipaca | zyga: because what it looks like is that the install is succeeding, and then snapcraft tries to do "snappy config", which fails | 10:00 |
| Chipaca | but the command that is in the traceback does not support that | 10:00 |
| zyga | Chipaca: please refresh my memory, what is snappy config? | 10:00 |
| Chipaca | so a possibility is that there's a broken try/except that's masking the proper command | 10:00 |
| Chipaca | zyga: a way for snaps to be configured | 10:00 |
| Chipaca | zyga: but it's separate from installation | 10:00 |
| Chipaca | zyga: you'd run 'sudo snappy config package < configfile' and the config file would be passed to a config hook in your package | 10:01 |
| Chipaca | zyga: (idea is to at some point have a schema so a config interface can be created automagically) | 10:01 |
| zyga | Chipaca: I don't have any hooks myself, where are hooks specified? are they per par or on the whole snap? | 10:02 |
| Chipaca | zyga: i could answer that question, but i believe you are misunderstanding what i think the problem is | 10:02 |
| Chipaca | zyga: your snap has no config | 10:03 |
| Chipaca | zyga: no config hook | 10:03 |
| Chipaca | zyga: so running "snappy config" will fail, with exactly the error you print | 10:03 |
| Chipaca | zyga: "snappy install" does not run "snappy config" | 10:03 |
| Chipaca | zyga: so it's possible snapcraft is running config after install itself | 10:03 |
| zyga | hmm, odd, is it? | 10:04 |
| Chipaca | zyga: you could confirm this if you did "snappy install" yourself, manually instead of through snapcraft | 10:04 |
| zyga | Chipaca: I read the code just now, it's not doing snappy config | 10:04 |
| zyga | Chipaca: it's only doing sudo snappy install *.snap | 10:04 |
| Chipaca | oooooooooohhhhhh | 10:05 |
| Chipaca | it's the *.snap thing! | 10:05 |
| Chipaca | snappy [OPTIONS] install [install-OPTIONS] [package name] [config file] | 10:05 |
| zyga | Chipaca: I have a patch for that section but I did not change the meaning really | 10:06 |
| zyga | ah | 10:06 |
| zyga | heheheh | 10:06 |
| zyga | nice! | 10:06 |
| zyga | Chipaca: I'll fix that localyl | 10:06 |
| zyga | Chipaca: and send you MRs | 10:06 |
| Chipaca | zyga: i hope that was a plural you :) 'cause i'm not on snapcraft right now | 10:06 |
| zyga | ah | 10:06 |
| zyga | I didn't know that | 10:06 |
| zyga | I'll just send it to lp:snapcraft, I'm sure someone can be poked into reviewing and landing them | 10:06 |
| Chipaca | zyga: thanks :) | 10:08 |
| mvo | ogra_: 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 weeks | 10:24 | |
| ogra_ | mvo, all fine and stable | 10:24 |
| mvo | yay! | 10:24 |
| mvo | \o/ | 10:24 |
| ogra_ | no issues so far | 10:24 |
| ogra_ | (at least i havent heard anything in that direction) | 10:24 |
| ogra_ | documentation updates are missing ... for the porting doc | 10:24 |
| mvo | ogra_: thanks, that sounds like (hopefully) something straightforward | 10: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 lunch | 11:12 | |
| * ogra_ hands Chipaca a faded map with a dotted line and cross on it | 11:13 | |
| davmor2 | Chipaca: 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 |
| ogra_ | omnomnomnom | 11:23 |
| mvo | Chipaca: 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 |
| ubottu | bug 1479711 in initramfs-tools-ubuntu-core (Ubuntu) "snappy should not mount with "discard" option" [Undecided,New] https://launchpad.net/bugs/1479711 | 11:57 |
| * ogra_ just uploaded the change to wily | 11:57 | |
| mvo | ogra_: probably yes | 11:59 |
| ogra_ | ok, i'll shelve it until i hear back from ricmm_ about the resize tests on 15.04 | 11: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 state | 12:09 |
| ogra_ | pitti, do you happen to have any hint for bug 1485683 ? smells like an ordering prob of the units or some such | 12:11 |
| ubottu | bug 1485683 in Snappy "/etc/sysctl.d is not applied on boot" [Undecided,New] https://launchpad.net/bugs/1485683 | 12:11 |
| kyrofa | ogra_, eh? No! | 12:24 |
| ogra_ | heh | 12:24 |
| pitti | ogra_: replied | 12:43 |
| kyrofa | ogra_, haha, read the article. Thanks for the reference! Indeed, not sure how informed the author was, but it's good press anyway :) | 12:45 |
| kyrofa | ogra_, 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 example | 12:48 |
| ogra_ | i guess there is a reason why it usually runs early | 12:48 |
| ogra_ | yeah, but it make one wonder why the snap scope needs I2C to work :) | 12:48 |
| ogra_ | *makes | 12:48 |
| ogra_ | heh | 12:48 |
| kyrofa | ogra_, yeah, my fault for writing about both in the same article :P | 12:49 |
| ogra_ | yeah, two topics in the same article is to much for some :) | 12:49 |
| kyrofa | ogra_, haha, I'll keep that in mind | 12:53 |
| ogra_ | wow, searching for snapcraft gets me a ton of minecraft posts on google | 13:41 |
| ogra_ | the actual howto is the pre-last hit | 13:41 |
| ogra_ | GRRR | 13:43 |
| * ogra_ curses finger memory | 13:44 | |
| ogra_ | ogra@anubis:~$ sudo snappy install snapcraft | 13:44 |
| ogra_ | Installing snapcraft | 13:44 |
| ogra_ | snapcraft failed to install: snappy package not found | 13:44 |
| ogra_ | :P | 13:44 |
| === davidcalle_ is now known as davidcalle | ||
| longsleep | Chipaca: 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 |
| nothal | Bug #1484641: snappy config command does not restart service after setting the configuration <Snappy:New> <http://launchpad.net/bugs/1484641> | 13:57 |
| ubottu | bug 1484641 in Snappy "snappy config command does not restart service after setting the configuration" [Undecided,New] https://launchpad.net/bugs/1484641 | 13:57 |
| Chipaca | longsleep: the config hook is run on install if you give it a config argument | 13:57 |
| ogra_ | bah | 13:57 |
| ogra_ | snapcraft downloading is unbelivable noisy | 13:58 |
| longsleep | Chipaca: config argument like snappy install mysnap --config ? | 13:58 |
| Chipaca | longsleep: 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 |
| longsleep | Chipaca: yes it would, though the docs say that the systemd service is restarted | 13:58 |
| longsleep | Chipaca: and that is the usual thing to do, and i think that cannot be done from the config hook can it? | 13:59 |
| Chipaca | longsleep: | 13:59 |
| Chipaca | snappy [OPTIONS] install [install-OPTIONS] [package name] [config file] | 13:59 |
| Chipaca | longsleep: (from snappy install --help) | 13:59 |
| Chipaca | interestingly, that does not appear in the manpage that's generated from the same information | 14:00 |
| Chipaca | silly go-flags | 14:00 |
| longsleep | Chipaca: 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 |
| Chipaca | longsleep: i don't remember offhand, but i can look | 14:02 |
| Chipaca | give me a sec | 14:02 |
| longsleep | cool thanks | 14:02 |
| Chipaca | longsleep: it looks like it's applied on first boot | 14:03 |
| longsleep | Chipaca: ok, well i think that is good enough for my purpose then. Where i pre populate various snap configs. | 14:05 |
| rickspencer3 | o/ | 14:06 |
| rickspencer3 | can anyone tell me what I am doing wrong here? | 14:06 |
| rickspencer3 | (BeagleBoneBlack)ubuntu@localhost:~$ sudo snappy update | 14:06 |
| rickspencer3 | another snappy is running, try again later | 14:06 |
| ogra_ | wow | 14:07 |
| * rickspencer3 braces | 14:07 | |
| rickspencer3 | ogra_, I assume I did something very silly? | 14:07 |
| ogra_ | no idea, i have never seen that :) | 14:07 |
| mvo | rickspencer3: nothing wrong, there is probably (90% confidence) just snappy autopilot running in the background and updating you | 14:07 |
| rickspencer3 | oh | 14:08 |
| mvo | rickspencer3: its doing that automatically every couple of hours | 14:08 |
| rickspencer3 | mvo, so, I just plugged it in for the first time in weeks, I guess it triggered then? | 14:08 |
| mvo | yeah | 14:08 |
| rickspencer3 | so, I just wait? | 14:08 |
| mvo | I guess we need to improve the error message or (even nicer) "attach" to the running snappy so that you can see what its doing | 14:08 |
| rickspencer3 | I guess I will get kicked out of my ssh session when it is done and reboots? | 14:09 |
| mvo | rickspencer3: yeah, just wait and/or check /var/log/syslog, iirc it prints some progress there | 14:09 |
| longsleep | try something like `ps ax|grep snappy` | 14:09 |
| rickspencer3 | mvo, would you like me to log a bug? | 14:09 |
| mvo | rickspencer3: it will inform you about the reboot and give you a chance to cancel it | 14:09 |
| mvo | rickspencer3: yeah, please do | 14:09 |
| ogra_ | mvo, we should make the message more clear | 14:11 |
| mvo | yep | 14:11 |
| longsleep | whoohoo mvo is processing all my bugs /cheer !! | 14:13 |
| rickspencer3 | mvo, enjoy bug #1488114 | 14:13 |
| nothal | Bug #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 |
| rickspencer3 | mvo, oh nice, I see it gives me 10 minutes before the automatic reboot | 14:15 |
| mvo | rickspencer3: yeah and it should also tell you how to cancel it | 14:18 |
| rickspencer3 | yeah, it's all very clear and nice | 14:19 |
| mvo | great | 14:19 |
| rickspencer3 | ogra_, 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.jpg | 14:23 |
| rickspencer3 | i.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 anything | 14:24 |
| ogra_ | (apart from telling you where P8_8 sits) | 14:24 |
| rickspencer3 | oh weird, it made the led glow slightly! | 14:24 |
| rickspencer3 | ogra_, maybe this one is better? | 14:25 |
| rickspencer3 | http://www.element14.com/community/servlet/JiveServlet/showImage/38-17874-209857/bbb-pinout.jpg | 14:25 |
| rickspencer3 | looks like it is GPIO_67 ? | 14:25 |
| ogra_ | rickspencer3, yeah, looks like you should be able to switch it by using GPIO_67 | 14:26 |
| beuno | rickspencer3, http://beagleboard.org/static/images/cape-headers-digital.png | 14:26 |
| beuno | I use that | 14:26 |
| * rickspencer3 looks | 14:26 | |
| ogra_ | well, pretty much the same | 14:26 |
| beuno | I guess it's the same, but has the nice colors to distinguish | 14:26 |
| beuno | yeah | 14:27 |
| beuno | but you get red for electrical stuff! | 14:27 |
| rickspencer3 | so, weird that it completed the circuit before I wrote any code! | 14:27 |
| rickspencer3 | I guess when the GPIO pin is unitialized, it sends it electricity ;) | 14:28 |
| rickspencer3 | now it's time to get control ;) | 14:28 |
| imuguruza | anyone using Snappy in OdroidC1?? | 14:30 |
| ogra_ | imuguruza, longsleep does | 14:31 |
| imuguruza | great, I just realized I have downloaded his img | 14:32 |
| imuguruza | longsleep: any chance of using I2C? | 14:32 |
| imuguruza | I have installed i2c-tools but can't open it | 14:33 |
| longsleep | imuguruza: you might have to load some modules | 15:02 |
| longsleep | imuguruza: i am using SPI with no problems, did not try I2C for a while | 15:02 |
| imuguruza | ok | 15:02 |
| imuguruza | I'm interested on SPI also | 15:03 |
| longsleep | well for spi you just load spicc and spidev module | 15:03 |
| longsleep | modprobe spicc | 15:03 |
| longsleep | modprobe spidev | 15:03 |
| longsleep | then you have /dev/spi.. and can use the examples from the linux kernel | 15:04 |
| longsleep | imuguruza: 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 |
| longsleep | ah yes | 15:05 |
| longsleep | modprobe aml_i2c | 15:05 |
| longsleep | should give you the i2c bus | 15:05 |
| imuguruza | longsleep: yes! | 15:06 |
| imuguruza | great, thanks! | 15:06 |
| longsleep | imuguruza: you are welcome | 15:07 |
| elopio | ogra_: 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/boottest | 15:24 |
| ogra_ | elopio, well, boot a VM with a new initrd and see if it comes up at all would be my first test | 15: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 bit | 15:26 |
| elopio | ogra_: 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 on | 15:27 |
| ogra_ | that would indicate that it failed to run | 15:27 |
| elopio | that 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 well | 15:28 |
| ogra_ | many bits are hidden sadly ... like mounting ... since usually the last step is to move-mount the bits and pieces | 15:29 |
| ogra_ | so the running system wouldnt see the initial mount or if there were failures ... | 15:29 |
| ogra_ | such bits we cant really test | 15:29 |
| elopio | ogra_: 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 initrd | 15:31 |
| elopio | if 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 that | 15: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 |
| elopio | ogra_: 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 |
| elopio | ogra_: I think you could add at least one log message so we can easily check that the script ran. | 15:34 |
| elopio | if you add many more messages, that would affect the boot time, right? | 15:35 |
| ogra_ | nah | 15:35 |
| ogra_ | it would just be some echos and redirects | 15:36 |
| ogra_ | shouldnt impact the boot time much | 15:36 |
| ogra_ | if something seriously went wrong with the default script you most likely wont finish booting anyway | 15:36 |
| ogra_ | the log would just be a finer grained view of what the general boot process did | 15:37 |
| elopio | ogra_: 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 |
| elopio | but for debugging, more logs will help. | 15:37 |
| ogra_ | indeed | 15:37 |
| === Michaela is now known as Mikaela | ||
| rsalveti | elopio: ogra_: we might also be able to mock some of the core pieces of the initrd code, and test that when building the package | 15:48 |
| rsalveti | besides checking for logs after the system booted | 15:49 |
| rsalveti | but yeah, as elopio said, need to check for the complexity | 15:49 |
| elopio | and I insist that running the script standalone in an already booted system gives some value. | 15:49 |
| ogra_ | yep | 15:49 |
| elopio | not a lot, but it will discover some obvious problems. | 15:49 |
| rsalveti | righy | 15:49 |
| rsalveti | *right | 15:49 |
| elopio | so during the boot, we can ignore those obvious problems and test for other things. | 15:50 |
| mcphail | Are 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 |
| longsleep | mcphail: Take a look at https://developer.ubuntu.com/en/snappy/snapcraft/ | 16:26 |
| mcphail | longsleep: 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 etc | 16:29 |
| === sarnold_ is now known as sarnold | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
