| tedg | jdstrand, By chance are you around? I'd like to get a snap approved in the store. | 02:04 |
|---|---|---|
| tedg | (it's tiny) | 02:04 |
| fgimenez | good morning | 07:02 |
| davidcalle | Morning o/ | 07:29 |
| longsleep | good morning all | 08:01 |
| longsleep | so - whats the state of images ? Can i fuse to 130 and then update to 131 and all should work? | 08:27 |
| ogra_ | yes | 08:34 |
| olli | gm | 08:35 |
| mvo | longsleep: see also my comment in #1477657, something fishy is going on with the delta generation right now | 08:36 |
| ogra_ | mvo, the same thing as always really ... and the reason why sergiusens switched to the versioned binary names | 08:37 |
| ogra_ | if the file didnt change system-image will simply not put it into the delta | 08:38 |
| ogra_ | also, the update seems to work fine despite the message | 08:39 |
| mvo | ogra_: yeah, its not a regression, still anoying | 08:41 |
| longsleep | ogra_: so the fix in the snappy tooling for rollback also fixed update? | 08:44 |
| * longsleep tries that | 08:44 | |
| longsleep | 130 has the fixed tool right? | 08:44 |
| ogra_ | ah, no, you need to copy the snappy binary over to 130 i think | 08:45 |
| ogra_ | after upgrading to 131 | 08:45 |
| ogra_ | at least if you want to do multiple back and forth rollback tests | 08:46 |
| mvo | ogra_: fwiw, fake-upgrade worked for me, I got auto-upgraded and rollback also works, looks like we are good here | 08:46 |
| longsleep | well the problem i had was that the update never touched uboot.env and thus automatic boot into the new system did not work | 08:46 |
| ogra_ | we definitely are | 08:46 |
| mvo | and re-upgrade too (all using fake versions though) | 08:47 |
| ogra_ | ricardo already copied 131 to alpha | 08:47 |
| longsleep | ah | 08:47 |
| longsleep | let me try that - i am all busy with sharing the kickstarter campaign .. | 08:47 |
| ogra_ | heh, looking good already | 08:47 |
| longsleep | anyone who wants to help - please share https://www.kickstarter.com/projects/spreed/spreedbox-the-most-private-video-chat-and-file-exc to make a cool Snappy device | 08:47 |
| ogra_ | (but your goal is also easy to achieve ... would be surprising if you dont make it | 08:48 |
| ogra_ | ) | 08:48 |
| ogra_ | did you send it to heise and golem.de ? | 08:49 |
| longsleep | well i hope so because i want the device for myself :D | 08:49 |
| longsleep | ogra_: i am not directly involved the the marketing | 08:49 |
| longsleep | thankfully :) | 08:49 |
| ogra_ | and ? | 08:49 |
| ogra_ | :P | 08:49 |
| longsleep | i leave that to others | 08:49 |
| longsleep | just spamming you guys here | 08:49 |
| ogra_ | just report it as news via their reporting mail addresses :) | 08:49 |
| longsleep | yeah i suppose i can do that thanks | 08:50 |
| ogra_ | if one of them picks it up you will have your goal in no time | 08:50 |
| longsleep | true - i am pretty sure that my colleagues are on that already - but more helps more :P | 08:50 |
| ogra_ | yeah | 08:51 |
| conyoo | longsleep, https://www.reddit.com/r/Ubuntu/comments/3efbx7/secure_and_private_video_conferencing_with_ubuntu/ | 08:53 |
| longsleep | conyoo: nice thanks ! | 08:53 |
| conyoo | np :P | 08:53 |
| * longsleep just received a shipmempt of ODROID-XU4's (USB3 + Gigabit Ethernet, Oktacore Exynos ARM) yay! | 09:04 | |
| davidcalle | conyoo, this looks excellent! | 09:06 |
| ogra_ | davidcalle, spread it ... share it ;) | 09:06 |
| mvo_ | longsleep: you are not in this video or are you? | 09:13 |
| ogra_ | mvo_, he is at the bottom in the pics | 09:14 |
| mvo_ | olli: thanks for the bugreport (and sorry for the delay, got disconnected) | 09:14 |
| Chipaca | mvo_: am looking at https://code.launchpad.net/~mvo/snappy/snappy-i18n-for-go-flags/+merge/264112 | 09:25 |
| Chipaca | mvo_: is there a reason for not iterating over options and setting each option description to i18n.G of the description after the parse? | 09:26 |
| Chipaca | or even before, actually | 09:26 |
| JamesTait | Good morning all; happy Friday, and happy Tequila Day! 😃 | 09:26 |
| Chipaca | mvo_: ah, maybe the concern is that xgettext won't find the strings that way | 09:27 |
| Chipaca | hmm | 09:27 |
| mvo_ | Chipaca: I'm not sure I understand the question, but yes, the string must be marked with something like i18n.G() so that it can be found | 09:28 |
| mvo_ | Chipaca: I think I understand the question now and yes, if the string is somehow marked this approach works fine | 09:28 |
| Chipaca | mvo_: actually my main beef with this approach is that you're iterating over a list of things multiple times instead of doing a single pass | 09:29 |
| Chipaca | mvo_: hmm :) | 09:29 |
| mvo_ | Chipaca: oh, I see, hmmmm | 09:30 |
| Chipaca | ooooh! i see a bug :) | 09:30 |
| mvo_ | Chipaca: fwiw, I tried to get upstream to make this easier but he was of the opinion its fine with the iterations | 09:31 |
| mvo_ | Chipaca: meeeh, a BUG? | 09:31 |
| Chipaca | a buggy bug | 09:31 |
| Chipaca | btw, me thinks hw-(.*) should be hw $1 | 09:32 |
| Chipaca | but anyways | 09:33 |
| mvo_ | Chipaca: yes | 09:33 |
| * mvo_ waits patiently for the buggy bug | 09:33 | |
| Chipaca | mvo_: line 422 | 09:34 |
| Chipaca | of the diff | 09:34 |
| Chipaca | sorry, was reading the whole thing again to catch similar ones | 09:35 |
| Chipaca | mvo_: can't find any other | 09:35 |
| Chipaca | so, anyway | 09:35 |
| mvo_ | yay, nice catch on r422 | 09:36 |
| mvo_ | l422 | 09:36 |
| Chipaca | mvo_: this way works; most things don't have that many options for it to be problematic | 09:36 |
| Chipaca | mvo_: however, i was wondering | 09:36 |
| Chipaca | mvo_: maybe we can arrange it so that each cmd either defines a per-cmd dict or adds to a global dict, and main.go does work? | 09:37 |
| longsleep | mvo_: i am in the video | 09:37 |
| longsleep | mvo_: at 1:40 or something | 09:38 |
| * Chipaca gives it a poke | 09:38 | |
| mvo_ | Chipaca: sounds like a good idea, I'm not super worried about the overhead of the iterations, but I like the elgance of it | 09:39 |
| * mvo_ will ponder over lunch | 09:39 | |
| conyoo | longsleep, https://news.ycombinator.com/item?id=9940909 | 09:50 |
| === conyoo is now known as conyoo|AW | ||
| Chipaca | mvo_: +1'ed your i18n flags branch; it needs a commit message though | 09:58 |
| Chipaca | mvo_: ditto your atomic branch | 09:58 |
| Chipaca | mvo_: and ditto your review tools branch | 10:02 |
| Chipaca | elopio: can i note that i disagree with you needsfixing things over % vs format? the recommendation of format is not even strong enough for pep8, and many people disagree | 10:07 |
| Chipaca | elopio: in particular, i think most of the time format only adds unreadableness for no benefit | 10:07 |
| longsleep | conyoo|AW: great thanks again! | 10:07 |
| Chipaca | elopio: also note i disagree in the -0 sense, not in the -1 sense | 10:07 |
| Chipaca | i mean, i can wade through unreadable code, and have done so for a living, so i don't worry too much about it | 10:08 |
| Chipaca | but ¯\_(ツ)_/¯ | 10:08 |
| === chihchun is now known as chihchun_afk | ||
| Chipaca | mvo_: what cna i do to help clear up the review queue? | 10:14 |
| Chipaca | it's massive | 10:14 |
| mvo_ | Chipaca: cleanup> is there more to do other than doing reviews :) ? iirc it was just that, iirc stuff was addressed its just a mater of approving or setting to needs-fixing etc | 10:21 |
| * mvo_ sets commit message | 10:22 | |
| mvo_ | s | 10:22 |
| rsalveti | fgimenez: mvo_: ogra_: I'll do a bit more testing in a few, but alpha looks fine | 10:31 |
| rsalveti | we need to make sure that we can do 6->7->6 | 10:31 |
| rsalveti | and that 3->7 can still work | 10:31 |
| ogra_ | rsalveti, how would 6-7-6 help if we only release 7 to the stable channel ? | 10:31 |
| ogra_ | or do you want to do two releases | 10:31 |
| rsalveti | because with 6->7->6 we can confirm that the next stable image will update successfully | 10:32 |
| ogra_ | ah, k | 10:33 |
| rsalveti | without fs corruption :-) | 10:33 |
| fgimenez | rsalveti, ok i'll begin with 6->7->6, you mean amd64 right? this morning armhf tip was 8 iirc | 10:33 |
| ogra_ | since we dont migrate people we should actually encourage a re-flash | 10:33 |
| rsalveti | hm, let me check | 10:33 |
| ogra_ | else they stay with the fatwrite forever | 10:33 |
| rsalveti | fgimenez: ogra_: yeah, sorry, 7->8->7 | 10:34 |
| fgimenez | rsalveti, ok | 10:34 |
| rsalveti | ogra_: right | 10:34 |
| longsleep | from that i understood, when the oem snap is updated boot resources are not written right? Is there any propsed way to update u-boot and consorts without reflashing? | 10:36 |
| ogra_ | longsleep, yes, in rolling | 10:37 |
| ogra_ | (only proposed afaik, not implemented yet) | 10:37 |
| fgimenez | Chipaca, thanks for the review! :) | 10:37 |
| mvo_ | yeah, Chipaca rocks | 10:38 |
| zyga | hey, do you plan to support upgrades from dual partition to single partition layout? | 10:41 |
| rsalveti | eventually, yes | 10:42 |
| rsalveti | since that would be the layout used by the phone | 10:42 |
| ogra_ | first we have to have the single partition layout :P | 10:43 |
| ogra_ | we're not even at prototype stage with that :) | 10:43 |
| mvo_ | longsleep: thats correct, only u-d-f deals with the boot-assets for now | 10:43 |
| mvo_ | longsleep: we have no plan, no. some ideas, but its tricky as the potential for screwup is huge | 10:43 |
| mvo_ | longsleep: as ogra_ pointed out the other day, powerfailure during uboot flash and its a brick | 10:44 |
| Chipaca | we can't just ship partitionmagic and let people sort it out? | 10:45 |
| Chipaca | i probably have it on a 3.5" somewhere | 10:45 |
| * ogra_ puts "floppy image" on his TODO | 10:45 | |
| zyga | Chipaca: and cyanide, once they give up ;) | 10:45 |
| Chipaca | we could ship a script that just wrote 0s over everything, and call it partitionmagic | 10:47 |
| Chipaca | when partitionmagic failed, we'd say "ah well, we tried; you'll have to reflash" | 10:47 |
| Chipaca | \o/ | 10:47 |
| * Chipaca should get lunch before he does anything *actually* crazy | 10:48 | |
| longsleep | mvo_: yes - but that is the same as with all devices - i think it would be nice to have some means to flash only u-boot environment | 10:50 |
| longsleep | i mean i do that all the time | 10:50 |
| longsleep | (manually with dd) | 10:50 |
| Chipaca | mvo_: I am suspicious of a branch that has two typos in the branch name alone | 10:51 |
| Chipaca | mvo_: but other than that https://code.launchpad.net/~mvo/snappy/snapy-out-own-xgettext/+merge/263659 seems fine :) | 10:52 |
| mvo_ | longsleep: good point indeed, so something like "snappy reflash"? or similar (well, name sucks) but essentially a snappy command to reinstall the bootloader? | 10:52 |
| mvo_ | Chipaca: pff, typos | 10:52 |
| Chipaca | mvo_: it's got a silly conflict, if you could fix that it's good to go i think | 10:52 |
| * Chipaca still doing the *actual* review, but it looks good | 10:52 | |
| mvo_ | Chipaca: my only concern with that branch is that its a big hammer for the `` but the alternatives seemd worse | 10:52 |
| longsleep | mvo_: yes - with the oem snap as provided input | 10:53 |
| mvo_ | longsleep: I like that idea a lot | 10:53 |
| Chipaca | it's a lovely bejewelled (glowing) (blessed) hammer of +2 i18nage | 10:53 |
| mvo_ | Chipaca: rotfl (and I don't use that term lightly!) | 10:53 |
| * Chipaca helps mvo_ up | 10:53 | |
| * mvo_ fires up nethack to get a real hammer | 10:54 | |
| ogra_ | you have been eaten by a grue | 10:55 |
| longsleep | mvo_: a tool like that could even gain a brain over time and check what is actually on the disk to do more complex migrations. | 10:56 |
| Chipaca | longsleep: i imagine that tool would come after the separation of the updater into its own thing | 10:56 |
| tbr | and then /dev/zombie comes by and eats it | 10:56 |
| Chipaca | longsleep: (so we can update the updater before updating the system) | 10:57 |
| Chipaca | which makes me think snappy would come in a .snap | 10:57 |
| Chipaca | which makes me think of the smalltalk type system | 10:57 |
| longsleep | Chipaca: well - i would see this as two things. One is for offline updater - doing a update like a new flash but without loosing data | 10:57 |
| longsleep | Chipaca: the other is on the system itself, making this possible without an extra PC | 10:58 |
| mvo_ | longsleep: yes, if you don't mind, file a bug and I will add it to the trello board | 10:58 |
| longsleep | mvo_: ok i can do that | 10:58 |
| mvo_ | longsleep: thanks! | 10:59 |
| Chipaca | mvo_: https://code.launchpad.net/~mvo/snappy/snappy-atomic-write-once/+merge/264125 also needs deconflicting | 11:03 |
| Chipaca | man, i let the review queue be too big for too long. sorry y'awl | 11:03 |
| Chipaca | conflicts everywhere | 11:04 |
| longsleep | mvo_: bug #1477950 added | 11:05 |
| nothal | Bug #1477950: Add tool to write OEM snap boot-assets to existing media <Snappy:New> <http://launchpad.net/bugs/1477950> | 11:05 |
| ubottu | bug 1477950 in Snappy "Add tool to write OEM snap boot-assets to existing media" [Undecided,New] https://launchpad.net/bugs/1477950 | 11:05 |
| fgimenez | rsalveti, i'm getting this when trying 7->8 http://paste.ubuntu.com/11929782/ | 11:26 |
| rsalveti | right, might be the issue we had that the kernel wasn't updated between such versions | 11:26 |
| rsalveti | mvo_: ogra_: ^ | 11:26 |
| ogra_ | thats harmless | 11:27 |
| rsalveti | we need to fix that at the system-image side | 11:27 |
| ogra_ | yeah | 11:27 |
| ogra_ | but mainly cosmetic atm ... longsleep opened a bug for it yesterday | 11:27 |
| longsleep | yes - the update should work. But i think the tool would show a messsage that one should reboot if that error would not happen. | 11:28 |
| longsleep | similar to snappy list | 11:28 |
| ogra_ | right | 11:28 |
| fgimenez | rsalveti, ogra_ longsleep yep http://paste.ubuntu.com/11929791/ rebooting now | 11:29 |
| rsalveti | hm, why is the oem 1.8? | 11:30 |
| longsleep | any chance that we can get a 132 edge 15.04 so i could test the upgrade path without replacing snappy tool in 130 ? | 11:30 |
| rsalveti | you should only use oem 1.8 when testing from 3->8 (fallback might fail) | 11:30 |
| rsalveti | and use latest oem when doing 7->8->7 | 11:30 |
| rsalveti | which is 1.11 | 11:30 |
| ogra_ | yeah | 11:30 |
| fgimenez | rsalveti, ah ok, first time i tried --oem beagleblack it booted into debian, i'll try again now | 11:40 |
| rsalveti | fgimenez: oh, if you got debian installed you also need to remove your current bootloader | 11:40 |
| rsalveti | fgimenez: or just unplug and plug power again with the boot switch pressed | 11:40 |
| fgimenez | rsalveti, ok | 11:40 |
| ogra_ | nah | 11:41 |
| ogra_ | S2 should be enough ... | 11:41 |
| ogra_ | you need to make it boot once from the SD and it will keep usign that | 11:41 |
| ogra_ | (by holding the S2 button i mean) | 11:41 |
| rsalveti | right | 11:41 |
| rsalveti | or | 11:41 |
| rsalveti | sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1024 count=1024 | 11:42 |
| ogra_ | yeah, but then you have no fallback if you want to debug on the board | 11:42 |
| rsalveti | well, we want to make sure people are always booting with our bootloader | 11:42 |
| rsalveti | otherwise we might have all sorts of issues | 11:42 |
| * ogra_ finds it pretty conveninet to be able to boot itno debian and mount the Sd partitions to check stuff | 11:42 | |
| ogra_ | right, indeed thats more for debugging | 11:43 |
| jdstrand | tedg: I'm here now | 12:30 |
| Chipaca | mvo_: what should service status output when no service is found? | 13:00 |
| tedg | jdstrand, Can you approve this app? It should be pretty straight forward, but I think you're the only one doing snaps today. https://myapps.developer.ubuntu.com/dev/click-apps/3195/ | 13:01 |
| longsleep | mvo_: can i somehow force snappy update to fetch a specific version? I am currently on 131 and would like to update the other partition to 131 as well | 13:08 |
| === davidcalle_ is now known as davidcalle | ||
| mterry | elopio, why is format ({}) considered better than % in python strings? | 13:18 |
| mvo_ | Chipaca: a good question, maybe simply nothing if there are none and the user did not specificy a search? | 13:21 |
| Chipaca | sounds fair | 13:21 |
| Chipaca | mvo_: and if the search is via webdm? | 13:21 |
| Chipaca | that is: is this a special case for the commandline only, or should i expose it to webdm too? | 13:22 |
| mvo_ | longsleep: you can do that in u-d-f, after its installed you can manually edit /etc/system-image/channel.ini and /etc/writable/cache/etc/system-image/channel.ini | 13:22 |
| mvo_ | Chipaca: I would say just return a empty list and no error? | 13:22 |
| mvo_ | Chipaca: unless there is a good reason for something else of course | 13:23 |
| Chipaca | mvo_: nope, that sounds sane to me | 13:23 |
| mvo_ | cool | 13:23 |
| jdstrand | tedg: ok, approved. You can of course fix the 'lint_description' warning easily enough. however I wonder why you are targetting amd64 if there are no binaries? | 13:27 |
| tedg | jdstrand, Because it seems that docker can only have one architecture per symbolic name. So that'll have to pull the amd64 image, and then I'll have to have a different name for arm, arm64, etc. | 13:28 |
| tedg | jdstrand, At some point I can probably script that, but I'm not there yet :-) | 13:28 |
| longsleep | mvo_: in u-d-f .. but my system is already installed and running. I would just want to a 'force update other to latest no matter what i have booted' | 13:41 |
| kickinz1 | ted, you can look at owncloud package, it checks the arch, then pull the corresponding image from registry. | 13:42 |
| longsleep | ogra_: what was the name of the tool again which creates snaps from deb files? | 13:43 |
| ogra_ | there is deb2snap and there is snapcraft | 13:43 |
| * longsleep remembers that he wanted to look at that | 13:43 | |
| longsleep | a snapcraft that was it | 13:43 |
| longsleep | thanks | 13:43 |
| longsleep | i guess http://www.snapcraft.net/ is not it :D | 13:44 |
| elopio | good morning. | 13:44 |
| longsleep | ok - ppa https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily is good to experiment with snapcraft? | 13:44 |
| zyga | hey | 13:47 |
| elopio | mterry: it has more features, some consider it cleaner (and I agree), and it's the new standard so all py3 should use it. | 13:49 |
| elopio | I find it cleaner specially because the strings tend to grow. You start with one argument, and it's common to end up with a string that has four arguments. | 13:49 |
| mterry | elopio, fair enough, just saw your link to the python2 docs about it | 13:49 |
| mterry | elopio, and it is nicer when you reuse the same argument. Can just do {0}, {0} twice | 13:50 |
| elopio | also I find it nice to use things like !r to format the value. There are some things to format decimals and stuff, but I haven't used them yet. | 13:50 |
| zyga | mterry: format is also better on tuples where % may misbehave if you don't do it carefully enough | 13:51 |
| mterry | fair | 13:51 |
| elopio | mterry: even "{nicely_named_arg1}, {nicely_named_arg1}".format(nicely_named_arg1='value') | 13:51 |
| mterry | elopio, so verbose! :) | 13:51 |
| rsalveti | longsleep: check https://code.launchpad.net/~mvo/snapcraft/docs-1/+merge/265770 as well | 13:51 |
| rsalveti | we're still working on getting it in a proper shape for release | 13:52 |
| elopio | mterry: yes indeed. Oh I like python very much. | 13:52 |
| elopio | I find it hard to switch from python to go, where everything uses short terms. On python I usually name a var index instead of i :) | 13:52 |
| elopio | that's so much better for reading code with my bad english. | 13:53 |
| mterry | elopio, beware carpal tunnel, man! | 13:54 |
| elopio | mterry: I have a shiny kinesis keyboard. He takes care of me and I of him. | 13:57 |
| longsleep | rsalveti: ok great - that looks promising thanks | 13:57 |
| elopio | Chipaca: noted your disagreement. | 13:58 |
| elopio | as it's -0, I prefer to go with the docs suggestion. | 13:59 |
| elopio | fgimenez: hey, I didn't notice that we can now start throwing tarmac integration runs to an ip in canonistack. | 14:05 |
| elopio | we just have to set it up with autoupdates and autoreboots. | 14:05 |
| elopio | they will fail of course, but they will fail with real regressions. | 14:05 |
| fgimenez | elopio, you mean having a running instance there always up, right? | 14:06 |
| elopio | fgimenez: yup. While we are ready with our throwable instances. | 14:07 |
| rsalveti | elopio: mterry: seems the amd64 build of snapcraft is failing https://launchpadlibrarian.net/212453342/buildlog_ubuntu-vivid-amd64.snapcraft_0-0~105~ubuntu15.04.1_BUILDING.txt.gz | 14:07 |
| rsalveti | when running the tests | 14:07 |
| mterry | humph | 14:07 |
| mterry | will look | 14:07 |
| fgimenez | elopio, yes, sounds good :) | 14:08 |
| elopio | mterry: rsalveti: Please, set your name with the 'whoami' command. | 14:08 |
| elopio | not sure how to solve that. I did it manually on tarmac. | 14:08 |
| elopio | I guess we can have a setup command on the plainbox tests? | 14:09 |
| mterry | elopio, whoami in what context? irc? | 14:09 |
| elopio | mterry: no, bzr whoami. | 14:09 |
| mterry | elopio, that is set for me | 14:09 |
| elopio | needed for the bzr commit that it's done in a couple of plainbox tests. | 14:09 |
| elopio | mterry: well, yes, on your machine you have it set for sure. But on the builders it's not. | 14:10 |
| mterry | elopio, I see what you're saying | 14:10 |
| mterry | elopio, stupid bzr shouldn't error out for that | 14:11 |
| elopio | or we could just put bzr whoami on the two tests, before bzr commit. | 14:11 |
| mterry | but i understand why it does | 14:11 |
| mterry | elopio, yeah easiest is just a quick dumb whoami in the tests | 14:11 |
| mterry | that way we don't rely on environment being configured right | 14:11 |
| elopio | mterry: sure. Will you do it or should I? | 14:11 |
| mterry | elopio, i will | 14:11 |
| elopio | tx | 14:12 |
| longsleep | mvo_: does the tutorial for snapcraft exist in some stage more than the stub in https://code.launchpad.net/~mvo/snapcraft/docs-1/+merge/265770 :D | 14:13 |
| mvo_ | longsleep: mterry will correct me if I'm wrong, but I think thats abot it right now, we are busy working on it thouhg and hope to have something more RSN | 14:13 |
| ogra_ | not yet :) | 14:13 |
| longsleep | ah just found the examples in the repository - i guess i will get it with those | 14:14 |
| longsleep | (Spreed WebRTC is a go server after all) | 14:14 |
| longsleep | mvo_: where does the software for the plugins come from? | 14:16 |
| mvo_ | longsleep: it can be various sources, launchpad, github, the archive, local | 14:17 |
| longsleep | mvo_: for example http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/plugins/go1.4.yaml - where does go1.4 come from / how does it know where to find it? | 14:18 |
| elopio | longsleep: are you working on spreedbox? that's nice! | 14:18 |
| longsleep | elopio: yeah i am | 14:19 |
| longsleep | mvo_: ok found it - it downloads it from https://storage.googleapis.com/golang/go1.4.2.linux-amd64.tar.gz | 14:20 |
| longsleep | mvo_: i am not sure if i like that - means builds cannot be automated if the build environment has no internet | 14:21 |
| longsleep | mvo_: i think snapcraft plugins should come from normal deb packages | 14:21 |
| longsleep | mvo_: or rather the third party gear | 14:22 |
| ogra_ | longsleep, why ? you could use a pluin (or wrtite one) that only uses debs ... and provide a local mirror | 14:22 |
| mvo_ | longsleep: well, its one way of doing it, there are more, you could have a go1.4 plugin that takes it from you local system for example | 14:22 |
| ogra_ | *plugin | 14:22 |
| longsleep | ah true - i can just provide my own plugins as python modules | 14:22 |
| mvo_ | longsleep: snapcraft mandates no policy here, its fine to write plugins that use debs of course | 14:22 |
| longsleep | got it | 14:22 |
| mvo_ | longsleep: and even plan to make it really easy to share them via some repository, so that other people benefit from your work | 14:22 |
| ogra_ | well it mandates a policy ... somehow ... "Go Wild !!" | 14:22 |
| mvo_ | haha, ok, it does | 14:23 |
| * longsleep likes 'wild' a lot | 14:23 | |
| longsleep | ok i will be making a spreed-webrtc snap with snappcraft next week then - will let you know how it goes and probably ask stupid questions | 14:24 |
| elopio | fgimenez: well, only detail is that snappy rolling edge is still not booting on canonistack | 14:26 |
| Chipaca | elopio: not booting, or not getting network? | 14:28 |
| elopio | Chipaca: hard to tell as I have no way to know what's happening. | 14:28 |
| elopio | it doesn't leave a log. | 14:28 |
| Chipaca | elopio: i haven't used canonistack; can't you reset an instance? like, hard reboot it? | 14:29 |
| Chipaca | elopio: or, better, can't you connect to a serial console of an instance? | 14:29 |
| ogra_ | or even mount the writable partition ? | 14:29 |
| ogra_ | from the outside | 14:29 |
| elopio | Chipaca: I can hard reboot. That's in progress. | 14:30 |
| longsleep | other questions folks: how can i install snaps which are not in the store / say i have them as a .snap file | 14:30 |
| Chipaca | or that, although i can't imagine building an api for that :) | 14:30 |
| elopio | I think the log is what comes from the serial console, maybe? don't really know. | 14:30 |
| Chipaca | elopio: so, if you let it boot the first time (give it plenty of time), then hard reboot it, it should come up with network the second time | 14:30 |
| Chipaca | elopio: if everything is alright :) | 14:30 |
| elopio | ok, /me waits for it. | 14:31 |
| * longsleep just discovered that snappy install somefile.snap seems to work | 14:31 | |
| Chipaca | there's an abundance of wishful thinking in that, but maybe :) | 14:31 |
| Chipaca | longsleep: what do you mean? | 14:31 |
| elopio | I think there's something else wrong, because the log of my other instances appear before the network is up. But lets see. | 14:32 |
| longsleep | Chipaca: when i built a snap for some software, how do i install it without the store | 14:32 |
| longsleep | Chipaca: just install from file ? | 14:32 |
| Chipaca | longsleep: yes | 14:32 |
| Chipaca | longsleep: it's called sideloading (your package will have origin: sideload) | 14:33 |
| longsleep | Chipaca: ok thats simple enough then | 14:33 |
| longsleep | Chipaca: all right - can i sideload during image creation in u-d-f as well? | 14:33 |
| ogra_ | yeap | 14:34 |
| ogra_ | use the --install option | 14:34 |
| longsleep | ok - so just ignore it is in the "Deprecated" section? | 14:35 |
| lool | elopio: funny that you bring this up, the integration tests fail if git config isn't set | 14:35 |
| lool | longsleep: heya | 14:35 |
| lool | longsleep: I'm sorry we didn't manage to finish our exchange | 14:35 |
| elopio | lool: I didn't see that error, but I suppose it would be the same, yes. | 14:35 |
| lool | longsleep: I see you've submitted a snap though :-) how did you end up approaching this? | 14:35 |
| longsleep | lool: no worries i had plenty of distraction here thanks | 14:36 |
| Chipaca | longsleep: where in "deprecated"? i see it under "development" here | 14:36 |
| lool | elopio: it was failing to me due to EMAIL/GIT_COMMITER_NAME etc. not being set in the test of snapcraft pull | 14:36 |
| longsleep | lool: the snap i submitted - you mean the ODROID oem snap? I just built it - that was quite simple. I published all the gear at https://github.com/longsleep/snappy-odroidc - might be helpful for other devices as well. | 14:37 |
| lool | longsleep: oh I thought you had submitted a spreed snap | 14:37 |
| longsleep | lool: no - not yet | 14:37 |
| longsleep | lool: i did build one though - but that was just hacking around | 14:37 |
| ogra_ | lool, we're keeping him busy with re-designing the uboot process | 14:38 |
| longsleep | yeah - but it turned out to be harder for you than it was for me i guess :) | 14:38 |
| lool | longsleep: ah there's a dummy spreed snap up for review, lol; I think it's just an empty one though | 14:38 |
| longsleep | lool: Who submitted that ? | 14:38 |
| longsleep | not me | 14:39 |
| lool | ogra_: eh, where's that happening? | 14:39 |
| ogra_ | lool, in 15.04 | 14:39 |
| lool | longsleep: no, mectors, I think it's something he threw together for iotworld, but I dont think he had time to touch it since | 14:39 |
| longsleep | lool: yes thats too - he sent me the details | 14:39 |
| ogra_ | lool, we moved away from txt files and fatwrite to using a binary blob environment file and put everything into variables | 14:39 |
| longsleep | lool: i will try snappcraft first and see how it goes and then submit one next week | 14:40 |
| longsleep | either with snapcraft or manually crafted | 14:40 |
| lool | mterry: heya | 14:40 |
| longsleep | lool: do you have some time to discuss the entropy issue? | 14:40 |
| lool | longsleep: snapcraft is comign really well; it's already able to deliver quite complex combinations | 14:40 |
| lool | longsleep: yes, with pleasure | 14:41 |
| mterry | elopio, rsalveti: sorry! my cafe internet expired. I'm back in my host's apt (I'm in NYC briefly) with wifi. trunk's use of whoami is fixed | 14:41 |
| mterry | lool, hi | 14:41 |
| lool | longsleep: TBH, I'm sleep deprived so my brain is quite in slow motion, but that kind of forces me to focus on one thing at a time like IRC or email | 14:41 |
| lool | mterry: would love to discuss some snapcraft bits when you have some time | 14:42 |
| longsleep | lool: ok great thanks - summary first - whenever a snappy device boots up first time it creates some stuff which requires entropy. On embedded devices there is essentially no entropy from standard kernel | 14:42 |
| mterry | lool, sure | 14:42 |
| longsleep | lool: means any key created on first boot is weak as it was created without entropy. | 14:42 |
| lool | longsleep: so what surprizes me is that this must be a common problem; how is this typically solved in other embedded systems? | 14:42 |
| longsleep | lool: it is a common problem yes - with embedded systems and with cloud systems as well | 14:43 |
| longsleep | lool: in embedded systems this is solved by having a HWRNG on chip which which feeds entropy into the kernel | 14:43 |
| elopio | mterry: lool mentioned we need to configure git too. "EMAIL/GIT_COMMITER_NAME etc. not being set in the test of snapcraft pull" | 14:44 |
| longsleep | lool: for this to work, ususally a system service is run (eg rngd or haveged) | 14:44 |
| mterry | elopio, lool: that doesn't seem to break the tests. is that just for correctness? | 14:45 |
| lool | mterry: so on the top of my mind: wanted to confirm the 2 branches I had submitted are now ready for review; I brought up the jre vs jdk thing in a bug report (and using host vs target deps/java runtime during build); then there are a couple of paper cuts I've hit; lastly, I have some feedback on the new copy/tarball plugins | 14:45 |
| longsleep | lool: for cloud stuff you folks at canonical implemented a rather scary entropy service providing random data over the network (managed by cloud-init) | 14:45 |
| lool | mterry: it broke the tests for me yesterday | 14:45 |
| lool | mterry: on a clean vm with no git config | 14:45 |
| mterry | lool, I saw your branches go by. I can start reviewing them, but did you want to talk about something outside the branches? | 14:45 |
| lool | mterry: I had to set the usual env vars (or I could have set git-config) for the tests to pass | 14:46 |
| lool | mterry: this broke snapcraft pull on top with the git commit -m 1, -m 2 etc. test | 14:46 |
| lool | mterry: topics I've listed above | 14:46 |
| lool | mterry: in no particular order | 14:46 |
| mterry | lool, ok... our buildd managed, but I guess it's a fragile thing | 14:46 |
| longsleep | lool: so to handle the problem, two things need to happen. Services which need entropy need to first start until there is sufficient entropy. On embeddded devices this usually means that rngd has been started. Only after, any private keys can be created. | 14:47 |
| longsleep | lool: or host keys for SSHD for that matter | 14:47 |
| tedg | I'm trying to install from the store and I'm getting "snappy package not found" | 14:47 |
| tedg | It shows up in "snappy list" though… | 14:47 |
| mterry | lool, right, but the topics you listed above seem like they are a list of the branches you submitted. I can look at them, but I haven't yet, so I may not have the context for the discussion that you want | 14:47 |
| tedg | Sorry snappy search | 14:47 |
| lool | longsleep: I'm scared by the entropy service in the cloud too; surprized there is no support from vm providers for this | 14:47 |
| lool | longsleep: the hardware generators feels like the msot natural | 14:48 |
| lool | longsleep: why does this need a daemon rather than the kernel just using it? | 14:48 |
| longsleep | lool: because there can be many sources for random data, and having them all in kernel space would be complicated | 14:48 |
| longsleep | lool: thus it is in user space | 14:48 |
| lool | longsleep: I remember a long debate upstream about using the Intel hw rng from Intel CPUs (and how the NSA could potentially use this), so seems it's already the case on x86? | 14:48 |
| longsleep | lool: see http://linux.die.net/man/8/rngd | 14:49 |
| lool | longsleep: makes sense | 14:49 |
| longsleep | lool: yes, the kernel uses some hardware rngs directly | 14:49 |
| lool | longsleep: so this seems like a rather core thing that should be there on all linuxes; how come we dont include it? | 14:49 |
| lool | mterry: the last topic was some feedback on tarball/copy plugins | 14:49 |
| lool | mterry: and the jre/jdk one is one which might need discussion | 14:50 |
| longsleep | lool: well - first of all most people do not care. Second, most PC's do not have a extra RNG hardware | 14:50 |
| longsleep | lool: there are USB dongles and such for it though | 14:50 |
| lool | mterry: otherwise, yes, the rest was just a heads up on branches I've pushed | 14:50 |
| mterry | lool, (I was off yesterday and will be off half today, so I've not had much time to review) | 14:50 |
| lool | longsleep: so on PCs, we use the CPU provided one, and on embedded systems there's often one and we just need rngd to use it | 14:51 |
| mterry | lool, lay your tarball/copy feedback on me :) | 14:51 |
| lool | mterry: that's fine; it's just a FYI because I've pushed a number of times to the branches and I wanted to clarify I was done for now | 14:51 |
| mterry | lool, cool, ACK | 14:51 |
| longsleep | lool: essentially yes - though it might also not be wise to always use one as some of them are really bad quality as well | 14:51 |
| lool | mterry: so the copy stuff is too minimal and I find it's clumsy to list the filenames directly as yaml keys | 14:52 |
| longsleep | lool: it should be a decision of the OEM provider how random is best created for this particular hardware | 14:52 |
| lool | mterry: I wanted to copy a dir over and couldn't, I wanted to do a shell glob and couldn't | 14:52 |
| mterry | lool, you should be able to copy a dir over.... that's intended and (I thought) tested | 14:52 |
| lool | didn't work for me, I think it's not a cp -r | 14:52 |
| longsleep | lool: i mean it is easy to provide a rngd snap, but the problem is that whatever first start stuff is done in snaps needs to rely on it | 14:52 |
| mterry | lool, ok... we could add a shell glob easily enough... you lose the ability to specify the destination easily. Unless it's a directory I guess | 14:53 |
| lool | res &= self.run(["cp", "--preserve=all", src, dst], cwd=os.getcwd()) | 14:53 |
| lool | that wont cp -r | 14:53 |
| mterry | lool, yup agreed. It was intended to do a directory. That got lost in the shuffle I guess | 14:53 |
| lool | longsleep: is rngd covering 98% of the use cases? | 14:54 |
| longsleep | lool: for example in the Spreedbox, we have 3 sources for entropy - SOC rng in the ARM chip, Linux Kernel interrupts and our own custom TRNG device. They all feed entropy in the kernel and only when there is say at least 300 bytes entropy any key can be created | 14:54 |
| longsleep | lool: yes - but only after it is started | 14:54 |
| longsleep | lool: trick is to not create anything before it is started | 14:54 |
| lool | longsleep: are all rngd providers upstream, or would one also need to configure/add providers? | 14:55 |
| lool | longsleep: is it just enabling a list or also configuring each differently | 14:55 |
| lool | longsleep: sounds like a typical boot job | 14:55 |
| longsleep | lool: one will want to add own ones - the device names are diffent, they could be connected by SPI, USB, on chip | 14:55 |
| lool | mterry: the tarball plugin, I wish we'd have a way to unpack to a subdir | 14:56 |
| lool | basically naming the toplevel now that we automatically strip it | 14:56 |
| mterry | lool, first you want to strip, now you don't! ;) | 14:56 |
| lool | mterry: and then, I've got bitten again with the "post-processing" use case | 14:56 |
| lool | mterry: eh | 14:56 |
| lool | mterry: well, having apache-tomcat-8.4.0/* was bad, but having LICENSE, README etc. all spread around is also bad | 14:57 |
| mterry | lool, I understand, I was just poking fun :) | 14:57 |
| lool | mterry: I guess ultimately we want some include/exclude between steps, but a dest dir is fine for now; it doesn't seem complex | 14:57 |
| ogra_ | mterry, stop implanting distrubing pics in my brain ! | 14:57 |
| lool | mterry: I kind of suspected you were :-) | 14:57 |
| longsleep | lool: on the odroidc the SOC device is called /dev/hwrng - the Ubuntu packge for rng-tools has some auto detection | 14:57 |
| mterry | ogra_, poking fun? | 14:58 |
| ogra_ | mterry, lool stripping | 14:58 |
| mterry | ogra_, haha | 14:58 |
| lool | longsleep: so I think the proper course of action is to propose this by default on Ubuntu | 14:58 |
| lool | perhaps only on some architectures | 14:58 |
| longsleep | lool: see http://paste.ubuntu.com/11930609/ for some examples | 14:58 |
| lool | it might have a consequence on boot time, and it needs a security review to go in main | 14:58 |
| lool | longsleep: but generally, it sounds like a piece of boot we are missing and which is quite important on some platforms | 14:59 |
| mterry | lool, yeah a prefix dir seems reasonable (it has been floated as a general thing for any given plugin, but such discussions are ongoing). Doens't hurt to add it to a case like the tar_content plugin that needs it most | 14:59 |
| lool | like setting the clock frmo hwclck | 14:59 |
| Chipaca | mvo_: pushed fixes to service | 14:59 |
| lool | mterry: post-processing: I mean that I wanted to fix files around (permissions, remove some, replace some, patch some) and couldn't because: a) there's no hook b) if you're a part Y after part X, it's not particularly easy to access part X c) when merging from multiple parts, file conflicts are explicitly prevented | 15:00 |
| lool | mterry: I dont know if hooks are the right answer, I dont like code mixed with the mostly declarative nature of snapcraft, so perhaps solving b) or allowing for c) would help enough | 15:01 |
| longsleep | lool: well - the Linux kernel is supposed to handle it. Newer linux kernels are supposed to set urandom blocking (similar to OpenBSD) until there is entropy. So the problem on some kernels is not so critical. Though, most ARM stuff from China runs on Kernel 3.10 which does no such thing. | 15:01 |
| lool | also, the various tarball/copy options we've discussed would make things less painful | 15:01 |
| mterry | lool, I'll make your nits into bugs so they don't get lost | 15:01 |
| mterry | lool, post-processing is a whole thing though | 15:02 |
| lool | longsleep: oh I didn't know urandom became blocking | 15:02 |
| lool | I thought the main point over dev/random was to NOT be blocking :-) | 15:02 |
| lool | I see where this is going though | 15:02 |
| lool | mterry: yup; sorry this is a bit unstructured, I wanted to share this while it's "fresh" in my mind if "fresh" can describe my current brain status | 15:03 |
| mterry | lool, :) | 15:03 |
| longsleep | lool: so for now i am looking for ways to include rngd in my image. Though i can do nothing about the weak SSH keys which get created on first boot | 15:04 |
| lool | longsleep: so this feels like a mature and simple daemon; I think we should consider it for Ubuntu boot sequence short term with a design on how sshd etc. would wait for that before generating keys; the longer term fix might be a systemd implementation, with slighlty more magic (e.g plugging an USB hw rng automatically adds it to the pool and such) | 15:04 |
| longsleep | lool: yeah sounds a good idea for all ARM based platforms if you ask me. | 15:05 |
| lool | longsleep: so I can't think of a fancy hook that could use; I can think of relatively heavy hacks | 15:05 |
| longsleep | hehe too bad | 15:05 |
| longsleep | well i am going to build my own rootfs - so i can even add more heavy hacks | 15:06 |
| lool | longsleep: what would seem the cleanest way would be to proof of concept this into the rootfs; either remounting yours rw, or building one from scratch; the heavy workaround would be to disable system services you dont want such as SSH and provide them yourself, but only after you've started your own copy of hw rng | 15:06 |
| longsleep | lool: well what would i give if snappy was using upstart :D | 15:07 |
| ogra_ | +1 | 15:07 |
| lool | haha | 15:07 |
| lool | I loved upstart | 15:07 |
| longsleep | me too | 15:07 |
| ogra_ | we wont get rid of it :) | 15:08 |
| longsleep | well we have all the gear for that random stuff for upstart | 15:08 |
| lool | oh really | 15:08 |
| * ogra_ herad there are no plans to move the unity8 sessions over to systemd | 15:08 | |
| lool | ok, I need to break away | 15:08 |
| longsleep | lool: yeah - a fistboot service which blocks | 15:08 |
| lool | I'm dead anyway | 15:08 |
| lool | longsleep: so I think next step is to engage in Ubuntu (and/or Debian!) discussions on enabling this on systemd systems and important services in the short term, and engaging with systemd upstream on a proper design | 15:09 |
| longsleep | lool: yes - i am still in the process on understanding the systemd boot and how it gets built into snappy rootfs | 15:10 |
| longsleep | lool: hacky but works just fine: http://paste.ubuntu.com/11930663/ | 15:13 |
| ogra_ | how do you mean "how it gets built into snappy rootfs" | 15:13 |
| * longsleep needs something similar for snappy | 15:13 | |
| ogra_ | we install debs in a chroot and then tar that up | 15:13 |
| longsleep | ogra_: yeah - and the device tree what happens with it? | 15:14 |
| ogra_ | separate | 15:14 |
| longsleep | i mean i guess i could just use our current rootfs builder to build the rootfs - just need to make it to work with snappy | 15:15 |
| lool | longsleep: so I find it weird that you read a load of entropy; if it's to make sure that it's coming from rngd, why not read it after it started? | 15:15 |
| ogra_ | for the supported arches we simply install the kernel deb into the chroot after the rootfs tarball was created ... and pick the bits out of the chroot into a device tarball | 15:15 |
| longsleep | lool: well yeah - this is just to make sure to get rid of any possible bad entropy | 15:16 |
| ogra_ | but that has nothoing to do with systemd | 15:16 |
| longsleep | bad means not so random | 15:16 |
| lool | longsleep: right, so perhaps do that after starting the daemon | 15:17 |
| longsleep | lool: yeah true - i guess it would be better that way | 15:17 |
| lool | first, this has less chances of blocking, second, you wont have more bad entropy created between the time where you read it and the daemon being ready | 15:17 |
| longsleep | lool: correct | 15:17 |
| longsleep | lool: let me change that in the repo :) | 15:21 |
| longsleep | lool: but i think i made my points clear, cloud-init and such would have to run after entropy is available. | 15:22 |
| longsleep | lool: we wait for 200 bytes - which is quite a lot | 15:22 |
| longsleep | check your devices: cat /proc/sys/kernel/random/entropy_avail | 15:23 |
| lool | longsleep: I suspect this will have to be benchmarked by cloud folks working on the images for various cloud providers | 15:23 |
| longsleep | probably fine right now (but check then on boot) | 15:23 |
| lool | longsleep: (one other thing they care about is boot time) | 15:23 |
| ogra_ | lool, lol | 15:24 |
| lool | sometimes, it's acceptable to have less security for not too valuable VMs or if the networking environment is closed | 15:24 |
| ogra_ | lool, so they developed cloud-init to make the boot time more interesting ? | 15:24 |
| longsleep | lool: well yes - i think cloud-init is beyond repair and snappy should just drop it and implement the three four things instead | 15:24 |
| ogra_ | longsleep, +1 | 15:24 |
| longsleep | lool: also for cloud images, you have the entropy service - so it should be quick and rngd would make no sense | 15:25 |
| lool | ogra_: I suspect that demos where one creates 2000 containers or vms will get impacted if we add something which might block for a random number of seconds/minutes | 15:25 |
| lool | say, this cloud provider has a broken this or that rng implementation and it blocks his boot, we'll be in hot water | 15:25 |
| ogra_ | lool, seriously, clud-init reliably adds 30-50 seconds to our boot process | 15:25 |
| ogra_ | not sure where the speedup should be here | 15:25 |
| lool | ogra_: I dont understand the argument you're making | 15:26 |
| lool | it's ok to slow down the boot because they've slowed it down already? | 15:26 |
| longsleep | lool: yeah - true though i think most cloud providers pre seed their images with a seed file. So the kernel has entropy instantly. | 15:26 |
| lool | I'm not worried about a small impact on the boot, but more of a random boot delay in some configurations | 15:26 |
| lool | longsleep: wow, you've had some strong words against cloud-init | 15:27 |
| ogra_ | lool, no, i'm sayin lets speed up the boot by getting rid of cloud-init ... i simpüly found your argument funny that cloud people care about bootspeed while we are constantly suffering from cloud-init doing exactly the opposite for us | 15:27 |
| ogra_ | (not to mention that we have distro tolls for everything cloud-init does and could simply use them) | 15:27 |
| ogra_ | *tools | 15:27 |
| longsleep | yeah it does a lot of things where only few will be used together - i guess it is valid for automatic deployments in clouds but i fail to see the need on embedded devices | 15:28 |
| longsleep | especially now that cloud init is the reason to ship python2 and python3 | 15:28 |
| longsleep | (as far as i see) | 15:28 |
| ogra_ | yes, that too | 15:28 |
| ogra_ | my biggest concern is that it is a reinvention of existing distro tools that wokrs a lot slower and adds extra pain where we could use saner methods to achieve the same | 15:29 |
| longsleep | i just say leave cloud init to clouds and do not use it in embedded devices :) | 15:29 |
| ogra_ | if the cloud peaople actually need images from us i would rather build an ubuntu-core-cloud rootfs then to have cloud-init everywhere | 15:30 |
| ogra_ | (and no, i dont belive that rewriting it in go is better than using distro ways for the bits we need) | 15:30 |
| lool | longsleep, ogra_: FYI, there's a cloud-init rewrite underway but it's still young https://github.com/stackforge/cloud-init | 15:32 |
| ogra_ | lool, yes :/ | 15:32 |
| ogra_ | not what i'm aiming for | 15:32 |
| * ogra_ wants it gone | 15:33 | |
| longsleep | if i really have to build own rootfs i guess it will not include cloud-init if i can make it work without it | 15:34 |
| longsleep | ogra_: btw - i have other challenges on boot as well, i need to set certain sysctl stuff - some can be set late, but others need to be set during initrd - any idea how i could do that from the oem or device parts? | 15:36 |
| ogra_ | not really, except for hacking the initrd ... which i wouldnt do | 15:36 |
| longsleep | ogra_: i am doing that already :D | 15:37 |
| ogra_ | (will be a pain to keep in sync) | 15:37 |
| ogra_ | and i want us to get to a generic initrd that nobody needs to change | 15:37 |
| ogra_ | (like we use on the phone) | 15:37 |
| longsleep | ogra_: currently i am only removing lib/modules and lib/firmware from the initrd i extracted from the preinstalled tarball | 15:38 |
| ogra_ | (sergio was working on that before he went on paternity leave) | 15:38 |
| longsleep | so i gess that is minimal | 15:38 |
| ogra_ | yeah, and the generic one would have that inside | 15:38 |
| ogra_ | *would not | 15:38 |
| longsleep | that would be ok, but i still have to add some scripts to init-top and init-bottom phases - how do you feel about that? | 15:41 |
| longsleep | i guess the other kernel settings could be made by a snap on boot (preferably the oem snap) | 15:42 |
| longsleep | can the oem snap provide services? | 15:42 |
| ogra_ | why do you need them that early ? | 15:43 |
| longsleep | ogra_: because DHCP might fail otherwise | 15:44 |
| ogra_ | uh ? | 15:44 |
| ogra_ | then we need to fix DHCP on the rootfs | 15:44 |
| longsleep | yeah .. some chip issues with certain switches | 15:44 |
| longsleep | no its a kernel driver thing | 15:44 |
| longsleep | the DHCP client is not responsible | 15:44 |
| ogra_ | hmm | 15:44 |
| longsleep | has todo with the interrupts which get used by default for the NIC | 15:45 |
| elopio | fgimenez: did you hit this one? https://bugs.launchpad.net/snappy/+bug/1477657 | 15:45 |
| ubottu | Launchpad bug 1477657 in Snappy "Snappy update fails because of its looking for non existing /writable/cache/assets/vmlinuz" [Critical,Confirmed] | 15:45 |
| ogra_ | so my idea is the following: http://paste.ubuntu.com/11930798/ ... theoretically you could also have an img file alongside that provides top or bottom scripts for the initrd to be loop mounted on demand | 15:45 |
| elopio | fgimenez: I'm seeing that message. | 15:46 |
| fgimenez | elopio, i've seen that this morning but it was updating anyway | 15:46 |
| longsleep | ogra_: sounds reasonable - though for me no modules are required in initrd | 15:46 |
| fgimenez | elopio, my current problem is that it refuses to boot in b... | 15:47 |
| longsleep | (i am not adding any modules or firmware) | 15:47 |
| elopio | fgimenez: well, but I would think that this bug leaves a corrupted b. | 15:47 |
| mterry | elopio, why in your format_strings1 branch, do you take setup_dirs() outside of the common test case class? | 15:47 |
| longsleep | ogra_: why would you put the system-a/b into squashfs images as well? | 15:47 |
| ogra_ | longsleep, sure, but thats the generic bit ... i dont want to have porters to touch the initrd at all | 15:48 |
| ogra_ | longsleep, saving space and being able to ship everything readonly on one partition | 15:48 |
| elopio | mterry: because not all tests need it. And when it is run, it will change the environment, so it needs a cleanup. | 15:48 |
| ogra_ | actually it shoudl rather look like http://paste.ubuntu.com/11930813/ | 15:48 |
| longsleep | ogra_: mhm ok - for this to work a general hook would be required so people can do things in initrd. | 15:48 |
| mterry | elopio, sure... so you could do addCleanup eh? I get about not all tests needing it. | 15:49 |
| elopio | mterry: so far there seems to be only one test needing it, so I put it there. If we need it in more places, we can make a specific test case for it | 15:49 |
| ogra_ | longsleep, as i said... there could be init-top.img and init-bottom-img | 15:49 |
| ogra_ | longsleep, so you would put your scripts inside and initrd would loop mount them in the respective script dirs | 15:49 |
| mterry | elopio, you also put a blank line before 'import yaml', I think under the belief that it's a local import? But it's not | 15:49 |
| longsleep | ogra_: oh yeah got it - that would be nice | 15:49 |
| ogra_ | that way you can provide your own script without having to mangle the default initrd | 15:50 |
| fgimenez | elopio, according to ogra_ and longsleep the update should work regardless of the error message, it's a cosmetic problem atm | 15:50 |
| ogra_ | fgimenez, right, it suppresses the reboot message though | 15:50 |
| elopio | mterry: it's third party. From pep8, you should put the std python imports, a newline, the third party imports, a new line and then the local imports. | 15:50 |
| mterry | elopio, if the pep8 tool doesn't care, I have a hard time caring. ;) But sure, OK. I get it | 15:51 |
| elopio | I should provide pep8-as-a-manual-service and make tons of money out of it. | 15:52 |
| mterry | elopio, or just fix the pep8 tool to catch this stuff :) | 15:53 |
| mterry | (does it have a --pedantic mode?) | 15:53 |
| jdstrand | tyhicks: this is kinda annoying: | 15:54 |
| jdstrand | Jul 24 15:50:35 localhost kernel: [ 261.778262] audit: type=1326 audit(1437753035.869:23): auid=1000 uid=1000 gid=1000 ses=1 pid=1016 comm="ls" exe="/bin/ls" sig=31 arch=c000003e syscall=41(socket) compat=0 ip=0x7f19462c40b7 code=0x0 | 15:54 |
| elopio | mterry: https://github.com/PyCQA/pep8/issues/329 | 15:54 |
| elopio | let's call it a --super-correct mode :) | 15:54 |
| jdstrand | tyhicks: I used 'ls -l <something>' in an app that didn't have 'network-client/networking' and got a socket() denial | 15:55 |
| jdstrand | seccomp arg parsing is getting to be more of a priority I think | 15:55 |
| mterry | elopio, in CommonTestCase.test_set_plugin, shouldn't you have an addCleanup? | 15:55 |
| tyhicks | probably so | 15:55 |
| tyhicks | I can't imagine why that would require a call to socket() | 15:55 |
| tyhicks | but it doesn't matter much | 15:55 |
| jdstrand | netlink? | 15:56 |
| tyhicks | possibly | 15:56 |
| jdstrand | yeah, I wasn't going to spend time looking at it. just mentioning that it is annoying | 15:56 |
| elopio | mterry: yes, I think I should have. | 15:56 |
| tyhicks | jdstrand: I agree that arg parsing is going to important soon | 15:56 |
| elopio | mterry: maybe, move that cleanup to the base TestCase ? | 15:57 |
| elopio | so it's always cleaned up even if it wasn't changed. | 15:57 |
| mterry | elopio, sure | 15:58 |
| mterry | elopio, it's going to look weird without the corresponding setup_dirs call, so maybe add a comment explaining why we don't do that call | 15:58 |
| elopio | ok. | 15:59 |
| elopio | mterry: I dislike this global var in the module. But I couldn't think of an alternative. | 15:59 |
| mterry | elopio, yeah the core of this code grew out of a prototype so some code barriers are a little loose | 16:00 |
| ash_charles | Hello. I'm running into a bug with ubuntu-device-flash (https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1464054) | 16:01 |
| ubottu | Launchpad bug 1464054 in goget-ubuntu-touch (Ubuntu) "Fails to create a snappy image when using --install" [Undecided,Confirmed] | 16:01 |
| elopio | mterry: could we try to use plugins from the local dir, and if not found, go to /usr/share ? | 16:01 |
| ash_charles | it looks like the bug has been fixed but I'm looking for a debian package for this code that includes the fix | 16:01 |
| ash_charles | any way to track down such a package? | 16:02 |
| mterry | elopio, you mean always look at ../../share/snapcraft/plugins? (where ../../ is relative path from wherever the python module for snapcraft is -- do we always know the install layout?) | 16:03 |
| mterry | whoops | 16:03 |
| mterry | I mean always look at ../../plugins | 16:03 |
| mterry | (that's the one for the bzr dir | 16:03 |
| jdstrand | tyhicks: erf, same with the 'id' command | 16:03 |
| ogra_ | ash_charles, https://launchpad.net/~snappy-dev/+archive/ubuntu/tools-proposed | 16:04 |
| mterry | elopio, ^ feels odd to go looking at what would be /usr/lib/python3/plugins | 16:04 |
| ogra_ | (note that there might land things that had zero QA though | 16:04 |
| ogra_ | ) | 16:04 |
| elopio | mterry: yes. Always try. Like putting on get_plugindir: | 16:04 |
| elopio | if os.path.exists(os.path.join(topdir, "setup.py")): | 16:04 |
| elopio | ../../plugins | 16:04 |
| elopio | else: | 16:04 |
| elopio | /usr/hsare | 16:04 |
| ash_charles | ogra_: thanks---I'll give this a whirl | 16:05 |
| mterry | elopio, I suppose... and then we can unit test that by mocking os.path.exists I guess | 16:06 |
| elopio | mterry: yes, I still find it weird. But I think I like better to delay the check, instead of having to run a previous setup_dirs step. | 16:06 |
| elopio | mterry: why don't we put the local plugins in ~/something, like bzr ? | 16:06 |
| mterry | elopio, ... those aren't local plugins | 16:06 |
| mterry | elopio, that check is testing whether we're running from a bzr checkout or not | 16:06 |
| elopio | oh, right. | 16:06 |
| elopio | there was something in pkg_resources that I think we used once... | 16:07 |
| longsleep | ogra_: there is another tool i would like to see on snappy by default: http://linux.die.net/man/8/fbset - any thoughts on that? | 16:08 |
| elopio | It was like we could use pkg_resources to find stuff, either installed or relative to the module. I don't really remember. | 16:08 |
| fgimenez | have a nice weekend o/ | 16:09 |
| elopio | any way, this is weird. I think we can find a better way to handle it. | 16:09 |
| ogra_ | longsleep, hmm, not really for embedded ... that soounds like something for snappy-personal | 16:09 |
| longsleep | ogra_: how do you control the framefuffer for bbb or rpi2 ? | 16:09 |
| davmor2 | ogra_: so why am I getting guid and uid issues following your guide to install snappy desktop? | 16:09 |
| ogra_ | we dont even enable graphical output on snappy devices yet | 16:09 |
| longsleep | ogra_: a that explains it then | 16:10 |
| davmor2 | ogra_: http://paste.ubuntu.com/11929712/ | 16:10 |
| longsleep | ogra_: i am showing a full screen logo now | 16:10 |
| ogra_ | and i think you dont really want fbset on embedded setups | 16:10 |
| ogra_ | davmor2, using the wily u-d-f ? | 16:10 |
| ogra_ | (pre-wily cant build personal) | 16:11 |
| davmor2 | ogra_: yes or it doesn't download at all :) | 16:11 |
| longsleep | ogra_: ok true - problem is that i need it in in initrd :/ so a snap would not help so much | 16:11 |
| mterry | lool, tar and tarfile don't handle evil paths automatically? That's stunning | 16:11 |
| ogra_ | longsleep, well, for that such a loop mounted img would serve as well :) | 16:11 |
| longsleep | ogra_: exactly | 16:12 |
| mvo_ | tarfile even warns about this in its docs, but yes, its stunning | 16:12 |
| ogra_ | davmor2, what version of u-d-f exactly ? | 16:12 |
| lool | mterry: yeah, it blew my mind too | 16:12 |
| davmor2 | ogra_: I installed ubuntu-device-flash_0.27-0ubuntu1_amd64.deb which is the wily version right | 16:12 |
| ogra_ | hmm, i'm even on 0.26 and it worked last time i tried personal | 16:13 |
| ash_charles | ogra_: thanks---this worked for me :) | 16:13 |
| davmor2 | ogra_: I just grabbed it from packages.ubuntu.com under wily :) http://paste.ubuntu.com/11930919/ see it has personal listed which the vivid one didn't | 16:14 |
| ogra_ | davmor2, there is bug 1470727 | 16:14 |
| ubottu | bug 1470727 in goget-ubuntu-touch (Ubuntu) "ubuntu-device-flash touch fails with: failed to find user uid/gid" [Undecided,Confirmed] https://launchpad.net/bugs/1470727 | 16:14 |
| ogra_ | but no movement on it | 16:14 |
| elopio | rsalveti: were you following federico's issue with update from 7 to 8? | 16:14 |
| elopio | I've just reproduce it. | 16:15 |
| davmor2 | ogra_: so this 9.1GB is crap then right which would explain why it doesn't run then right :) | 16:15 |
| ogra_ | most likely, yes | 16:15 |
| rsalveti | elopio: not yet, which issue? | 16:16 |
| rsalveti | (still on call) | 16:16 |
| davmor2 | ogra_: that's fine as long as I know it is not something else :) | 16:16 |
| ogra_ | i would try to confirm, but i dont really feel like doing a 2h download right now | 16:16 |
| davmor2 | ogra_: not a worry dude just wanted to be sure :) | 16:16 |
| ogra_ | definitely a u-d-f thing i think | 16:17 |
| * mvo_ gets dinner, telegram if the world explodes | 16:17 | |
| elopio | rsalveti: flash 15.04 alpha#7, update to #8, reboot. It returns to #7, but keeps #8 selected for the next reboot. | 16:17 |
| elopio | ogra_: was it you he was working on it? ^ I don't remember what he said. | 16:18 |
| davmor2 | mvo_: telegram telegram telegram.......oh wait no your safe just some muppet letting of fireworks ;) | 16:20 |
| davmor2 | you're even | 16:20 |
| ogra_ | elopio, 7 has a broken snappy still | 16:21 |
| ogra_ | i only tested on the edge channel from 130 to 131 | 16:21 |
| * Chipaca just leaves this here: http://www.cnx-software.com/2015/07/22/odroid-c1-board-is-an-upcoming-upgrade-to-odroid-c1-board/ | 16:21 | |
| longsleep | ogra_: cant you guys just trigger a 132 so we could test a real update with uboot.env ? | 16:22 |
| ogra_ | rsalveti, ^^^ what do you think ? | 16:22 |
| longsleep | Chipaca: yeah the Spreedbox will have the ODROID-C1+ | 16:23 |
| mterry | elopio, you use {!r} for a path. Why is repr preferred for a path? | 16:24 |
| rsalveti | ogra_: sure, just trigger it | 16:24 |
| elopio | mterry: not for a path. For a string that you want to keep quoted. | 16:24 |
| ogra_ | longsleep, rsalveti ... build running | 16:25 |
| elopio | we have an inconsistent use of things that we keep quoted and things that we don't. But if we want quotes, !r makes it nicely. | 16:25 |
| mterry | elopio, that seems like a really backdoor way to get quotes. repr is defined as a string that eval can consume. It happens to have quotes for some things but maybe the object passed to format is a complex object whose str() and repr() are very different. Isn't it more robust to just put the two ' quote strings in the message itself? It's the same number of characters. It also lets translators use language-specific quotes (some languages do << an | 16:27 |
| mterry | d >> right?) | 16:27 |
| mterry | elopio, (not that we translate snapcraft yet) | 16:27 |
| ogra_ | rsalveti, oh, and i got the ok to seed ubuntu-fan now | 16:30 |
| ogra_ | (and the dnsmasq dep is actually gone i was told) | 16:30 |
| elopio | mterry: I had the feeling that !r was better, but you broke it for me. I'll replace it. | 16:32 |
| mterry | elopio, actually, if you wanted to be REALLY fancy, you'd use unicode curved quotes too | 16:32 |
| mterry | :) | 16:32 |
| elopio | ツ | 16:37 |
| * longsleep cannot grep anything because the stuff has so many typos :/ | 16:40 | |
| longsleep | kernel get hdmimode form uboot is 720p | 16:41 |
| longsleep | of course i grepped for "from uboot" ... | 16:41 |
| longsleep | is there some snappy logo artwork (svg or similar) i can use to display on the odroid? | 16:44 |
| longsleep | now that i can display full screen logos whould be a shame to ship a oem snap without one | 16:44 |
| * ogra_ would just grab the one from the websire | 16:45 | |
| ogra_ | *site | 16:45 |
| longsleep | if i would find a svg | 16:45 |
| longsleep | svn source for this one would be nice: http://1.bp.blogspot.com/-WgJN2_s3n5s/Va02zVflRDI/AAAAAAAA944/Sfi8vpEqNgQ/s1600/Screenshot%252Bfrom%252B2015-07-20%252B12%25253A58%25253A17.png | 16:46 |
| ogra_ | potrace ftw ;) | 16:46 |
| longsleep | err no :P | 16:46 |
| Rlyeh | Hello guys | 16:54 |
| Rlyeh | Ogra_, I want to install the "OS.js". It's not available in snappy store, but in uappexplorer.com! How Can I install it on BBB? | 16:54 |
| ogra_ | Rlyeh, it wont be installable currently ... the format of snaps changed and i didnt find the time to port the os.js snap over | 16:55 |
| ogra_ | http://people.canonical.com/~ogra/snappy/snaps/ you could try to sideload it ... but i'm pretty sure snappy will just error and tell you that snaps with namespace arent allowed | 16:56 |
| longsleep | ogra_: did you push the updated BBB oem snap to the store already? | 16:56 |
| ogra_ | longsleep, mvo did | 16:56 |
| ogra_ | shoudl be at 1.11 | 16:56 |
| longsleep | ogra_: so it will just not work when you install that OEM with stable channel? | 16:56 |
| ogra_ | longsleep, not until we released the rootfs | 16:57 |
| longsleep | ogra_: ok - so i suppose i can add this breakage too then | 16:57 |
| ogra_ | Rlyeh, i'll try to get to that on the weekend and will produce a new OSjs snap | 16:58 |
| Rlyeh | ogra_, Greaaaaaaaaaaat. Thank you :) | 16:59 |
| ogra_ | np, it was low on my prio list since i didnt actually expect any users :) | 17:00 |
| Rlyeh | It's an useful app for snappy | 17:00 |
| ogra_ | yeah, ist a fun thing | 17:00 |
| longsleep | yeah autopilot just triggered | 17:01 |
| ogra_ | oh, really ? | 17:03 |
| ogra_ | i dont see the new rootfs on system-image yet | 17:03 |
| longsleep | yeah i also do not get what it actually did | 17:03 |
| longsleep | seems i am booted to 129 for some reason | 17:04 |
| ogra_ | lovely | 17:04 |
| longsleep | probably changed to many vars manually | 17:04 |
| ogra_ | yeah | 17:04 |
| ogra_ | i had the same issue yesterday | 17:04 |
| ogra_ | being on b while the system expected a | 17:04 |
| longsleep | exactly | 17:04 |
| longsleep | let my try to clean this up | 17:05 |
| * ogra_ just did a clean re-flash | 17:05 | |
| ogra_ | ah | 17:05 |
| longsleep | i guess i should do that too | 17:05 |
| ogra_ | and there is 132 | 17:05 |
| longsleep | at least now i am at 131 | 17:06 |
| longsleep | so lets try update then | 17:06 |
| longsleep | so far so good - it replaced the old 129 - now reboot | 17:07 |
| longsleep | yah | 17:08 |
| longsleep | (ODROIDC)ubuntu@odroid:~$ snappy list -v | 17:08 |
| longsleep | Name Date Version Developer | 17:08 |
| longsleep | ubuntu-core 2015-07-24 132 ubuntu* | 17:08 |
| longsleep | ubuntu-core 2015-07-23 131 ubuntu | 17:08 |
| longsleep | odroidc 2015-07-23 0.3 * | 17:08 |
| longsleep | worked like a charm | 17:08 |
| longsleep | great job! | 17:08 |
| ogra_ | :D | 17:09 |
| ogra_ | was your job too ... dont underestimate how much you helped us :) | 17:09 |
| longsleep | ogra_: well i try to help myself and get need to get detail understanding how things work with snappy. And you guys are really helpful with that - i highly appreciate it | 17:10 |
| === balloons_ is now known as balloons | ||
| === balloons39 is now known as balloons | ||
| Rlyeh | How can I change timezone? I read about 'config' command, but I don't understand how to set the timezone! | 17:38 |
| Rlyeh | "(BeagleBoneBlack)ubuntu@localhost:~$ snappy config ubuntu-core" just returns values :( | 17:42 |
| lazyPower | question, if i need to modify the docker sandbox on the arm2 package, i should be able to just edit the snap in /apps/docker/current/meta/packageyaml and rebuild/isntall from this on the host correct? | 19:46 |
| lazyPower | s/arm2/armhf/ | 19:46 |
| === ev_ is now known as ev | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
