[02:04] jdstrand, By chance are you around? I'd like to get a snap approved in the store. [02:04] (it's tiny) [07:02] good morning [07:29] Morning o/ [08:01] good morning all [08:27] so - whats the state of images ? Can i fuse to 130 and then update to 131 and all should work? [08:34] yes [08:35] gm [08:36] longsleep: see also my comment in #1477657, something fishy is going on with the delta generation right now [08:37] mvo, the same thing as always really ... and the reason why sergiusens switched to the versioned binary names [08:38] if the file didnt change system-image will simply not put it into the delta [08:39] also, the update seems to work fine despite the message [08:41] ogra_: yeah, its not a regression, still anoying [08:44] ogra_: so the fix in the snappy tooling for rollback also fixed update? [08:44] * longsleep tries that [08:44] 130 has the fixed tool right? [08:45] ah, no, you need to copy the snappy binary over to 130 i think [08:45] after upgrading to 131 [08:46] at least if you want to do multiple back and forth rollback tests [08:46] ogra_: fwiw, fake-upgrade worked for me, I got auto-upgraded and rollback also works, looks like we are good here [08:46] 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] we definitely are [08:47] and re-upgrade too (all using fake versions though) [08:47] ricardo already copied 131 to alpha [08:47] ah [08:47] let me try that - i am all busy with sharing the kickstarter campaign .. [08:47] heh, looking good already [08:47] 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:48] (but your goal is also easy to achieve ... would be surprising if you dont make it [08:48] ) [08:49] did you send it to heise and golem.de ? [08:49] well i hope so because i want the device for myself :D [08:49] ogra_: i am not directly involved the the marketing [08:49] thankfully :) [08:49] and ? [08:49] :P [08:49] i leave that to others [08:49] just spamming you guys here [08:49] just report it as news via their reporting mail addresses :) [08:50] yeah i suppose i can do that thanks [08:50] if one of them picks it up you will have your goal in no time [08:50] true - i am pretty sure that my colleagues are on that already - but more helps more :P [08:51] yeah [08:53] longsleep, https://www.reddit.com/r/Ubuntu/comments/3efbx7/secure_and_private_video_conferencing_with_ubuntu/ [08:53] conyoo: nice thanks ! [08:53] np :P [09:04] * longsleep just received a shipmempt of ODROID-XU4's (USB3 + Gigabit Ethernet, Oktacore Exynos ARM) yay! [09:06] conyoo, this looks excellent! [09:06] davidcalle, spread it ... share it ;) [09:13] longsleep: you are not in this video or are you? [09:14] mvo_, he is at the bottom in the pics [09:14] olli: thanks for the bugreport (and sorry for the delay, got disconnected) [09:25] mvo_: am looking at https://code.launchpad.net/~mvo/snappy/snappy-i18n-for-go-flags/+merge/264112 [09:26] 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] or even before, actually [09:26] Good morning all; happy Friday, and happy Tequila Day! 😃 [09:27] mvo_: ah, maybe the concern is that xgettext won't find the strings that way [09:27] hmm [09:28] 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] Chipaca: I think I understand the question now and yes, if the string is somehow marked this approach works fine [09:29] 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] mvo_: hmm :) [09:30] Chipaca: oh, I see, hmmmm [09:30] ooooh! i see a bug :) [09:31] Chipaca: fwiw, I tried to get upstream to make this easier but he was of the opinion its fine with the iterations [09:31] Chipaca: meeeh, a BUG? [09:31] a buggy bug [09:32] btw, me thinks hw-(.*) should be hw $1 [09:33] but anyways [09:33] Chipaca: yes [09:33] * mvo_ waits patiently for the buggy bug [09:34] mvo_: line 422 [09:34] of the diff [09:35] sorry, was reading the whole thing again to catch similar ones [09:35] mvo_: can't find any other [09:35] so, anyway [09:36] yay, nice catch on r422 [09:36] l422 [09:36] mvo_: this way works; most things don't have that many options for it to be problematic [09:36] mvo_: however, i was wondering [09:37] 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] mvo_: i am in the video [09:38] mvo_: at 1:40 or something [09:38] * Chipaca gives it a poke [09:39] 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:50] longsleep, https://news.ycombinator.com/item?id=9940909 === conyoo is now known as conyoo|AW [09:58] mvo_: +1'ed your i18n flags branch; it needs a commit message though [09:58] mvo_: ditto your atomic branch [10:02] mvo_: and ditto your review tools branch [10:07] 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] elopio: in particular, i think most of the time format only adds unreadableness for no benefit [10:07] conyoo|AW: great thanks again! [10:07] elopio: also note i disagree in the -0 sense, not in the -1 sense [10:08] 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] but ¯\_(ツ)_/¯ === chihchun is now known as chihchun_afk [10:14] mvo_: what cna i do to help clear up the review queue? [10:14] it's massive [10:21] 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:22] * mvo_ sets commit message [10:22] s [10:31] fgimenez: mvo_: ogra_: I'll do a bit more testing in a few, but alpha looks fine [10:31] we need to make sure that we can do 6->7->6 [10:31] and that 3->7 can still work [10:31] rsalveti, how would 6-7-6 help if we only release 7 to the stable channel ? [10:31] or do you want to do two releases [10:32] because with 6->7->6 we can confirm that the next stable image will update successfully [10:33] ah, k [10:33] without fs corruption :-) [10:33] rsalveti, ok i'll begin with 6->7->6, you mean amd64 right? this morning armhf tip was 8 iirc [10:33] since we dont migrate people we should actually encourage a re-flash [10:33] hm, let me check [10:33] else they stay with the fatwrite forever [10:34] fgimenez: ogra_: yeah, sorry, 7->8->7 [10:34] rsalveti, ok [10:34] ogra_: right [10:36] 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:37] longsleep, yes, in rolling [10:37] (only proposed afaik, not implemented yet) [10:37] Chipaca, thanks for the review! :) [10:38] yeah, Chipaca rocks [10:41] hey, do you plan to support upgrades from dual partition to single partition layout? [10:42] eventually, yes [10:42] since that would be the layout used by the phone [10:43] first we have to have the single partition layout :P [10:43] we're not even at prototype stage with that :) [10:43] longsleep: thats correct, only u-d-f deals with the boot-assets for now [10:43] longsleep: we have no plan, no. some ideas, but its tricky as the potential for screwup is huge [10:44] longsleep: as ogra_ pointed out the other day, powerfailure during uboot flash and its a brick [10:45] we can't just ship partitionmagic and let people sort it out? [10:45] i probably have it on a 3.5" somewhere [10:45] * ogra_ puts "floppy image" on his TODO [10:45] Chipaca: and cyanide, once they give up ;) [10:47] we could ship a script that just wrote 0s over everything, and call it partitionmagic [10:47] when partitionmagic failed, we'd say "ah well, we tried; you'll have to reflash" [10:47] \o/ [10:48] * Chipaca should get lunch before he does anything *actually* crazy [10:50] 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] i mean i do that all the time [10:50] (manually with dd) [10:51] mvo_: I am suspicious of a branch that has two typos in the branch name alone [10:52] mvo_: but other than that https://code.launchpad.net/~mvo/snappy/snapy-out-own-xgettext/+merge/263659 seems fine :) [10:52] 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] Chipaca: pff, typos [10:52] 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] Chipaca: my only concern with that branch is that its a big hammer for the `` but the alternatives seemd worse [10:53] mvo_: yes - with the oem snap as provided input [10:53] longsleep: I like that idea a lot [10:53] it's a lovely bejewelled (glowing) (blessed) hammer of +2 i18nage [10:53] Chipaca: rotfl (and I don't use that term lightly!) [10:53] * Chipaca helps mvo_ up [10:54] * mvo_ fires up nethack to get a real hammer [10:55] you have been eaten by a grue [10:56] 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] longsleep: i imagine that tool would come after the separation of the updater into its own thing [10:56] and then /dev/zombie comes by and eats it [10:57] longsleep: (so we can update the updater before updating the system) [10:57] which makes me think snappy would come in a .snap [10:57] which makes me think of the smalltalk type system [10:57] 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:58] Chipaca: the other is on the system itself, making this possible without an extra PC [10:58] longsleep: yes, if you don't mind, file a bug and I will add it to the trello board [10:58] mvo_: ok i can do that [10:59] longsleep: thanks! [11:03] mvo_: https://code.launchpad.net/~mvo/snappy/snappy-atomic-write-once/+merge/264125 also needs deconflicting [11:03] man, i let the review queue be too big for too long. sorry y'awl [11:04] conflicts everywhere [11:05] mvo_: bug #1477950 added [11:05] Bug #1477950: Add tool to write OEM snap boot-assets to existing media [11:05] bug 1477950 in Snappy "Add tool to write OEM snap boot-assets to existing media" [Undecided,New] https://launchpad.net/bugs/1477950 [11:26] rsalveti, i'm getting this when trying 7->8 http://paste.ubuntu.com/11929782/ [11:26] right, might be the issue we had that the kernel wasn't updated between such versions [11:26] mvo_: ogra_: ^ [11:27] thats harmless [11:27] we need to fix that at the system-image side [11:27] yeah [11:27] but mainly cosmetic atm ... longsleep opened a bug for it yesterday [11:28] 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] similar to snappy list [11:28] right [11:29] rsalveti, ogra_ longsleep yep http://paste.ubuntu.com/11929791/ rebooting now [11:30] hm, why is the oem 1.8? [11:30] 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] you should only use oem 1.8 when testing from 3->8 (fallback might fail) [11:30] and use latest oem when doing 7->8->7 [11:30] which is 1.11 [11:30] yeah [11:40] rsalveti, ah ok, first time i tried --oem beagleblack it booted into debian, i'll try again now [11:40] fgimenez: oh, if you got debian installed you also need to remove your current bootloader [11:40] fgimenez: or just unplug and plug power again with the boot switch pressed [11:40] rsalveti, ok [11:41] nah [11:41] S2 should be enough ... [11:41] you need to make it boot once from the SD and it will keep usign that [11:41] (by holding the S2 button i mean) [11:41] right [11:41] or [11:42] sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1024 count=1024 [11:42] yeah, but then you have no fallback if you want to debug on the board [11:42] well, we want to make sure people are always booting with our bootloader [11:42] 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:43] right, indeed thats more for debugging [12:30] tedg: I'm here now [13:00] mvo_: what should service status output when no service is found? [13:01] 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:08] 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 === davidcalle_ is now known as davidcalle [13:18] elopio, why is format ({}) considered better than % in python strings? [13:21] Chipaca: a good question, maybe simply nothing if there are none and the user did not specificy a search? [13:21] sounds fair [13:21] mvo_: and if the search is via webdm? [13:22] that is: is this a special case for the commandline only, or should i expose it to webdm too? [13:22] 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] Chipaca: I would say just return a empty list and no error? [13:23] Chipaca: unless there is a good reason for something else of course [13:23] mvo_: nope, that sounds sane to me [13:23] cool [13:27] 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:28] 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] jdstrand, At some point I can probably script that, but I'm not there yet :-) [13:41] 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:42] ted, you can look at owncloud package, it checks the arch, then pull the corresponding image from registry. [13:43] ogra_: what was the name of the tool again which creates snaps from deb files? [13:43] there is deb2snap and there is snapcraft [13:43] * longsleep remembers that he wanted to look at that [13:43] a snapcraft that was it [13:43] thanks [13:44] i guess http://www.snapcraft.net/ is not it :D [13:44] good morning. [13:44] ok - ppa https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily is good to experiment with snapcraft? [13:47] hey [13:49] 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] 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] elopio, fair enough, just saw your link to the python2 docs about it [13:50] elopio, and it is nicer when you reuse the same argument. Can just do {0}, {0} twice [13:50] 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:51] mterry: format is also better on tuples where % may misbehave if you don't do it carefully enough [13:51] fair [13:51] mterry: even "{nicely_named_arg1}, {nicely_named_arg1}".format(nicely_named_arg1='value') [13:51] elopio, so verbose! :) [13:51] longsleep: check https://code.launchpad.net/~mvo/snapcraft/docs-1/+merge/265770 as well [13:52] we're still working on getting it in a proper shape for release [13:52] mterry: yes indeed. Oh I like python very much. [13:52] 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:53] that's so much better for reading code with my bad english. [13:54] elopio, beware carpal tunnel, man! [13:57] mterry: I have a shiny kinesis keyboard. He takes care of me and I of him. [13:57] rsalveti: ok great - that looks promising thanks [13:58] Chipaca: noted your disagreement. [13:59] as it's -0, I prefer to go with the docs suggestion. [14:05] fgimenez: hey, I didn't notice that we can now start throwing tarmac integration runs to an ip in canonistack. [14:05] we just have to set it up with autoupdates and autoreboots. [14:05] they will fail of course, but they will fail with real regressions. [14:06] elopio, you mean having a running instance there always up, right? [14:07] fgimenez: yup. While we are ready with our throwable instances. [14:07] 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] when running the tests [14:07] humph [14:07] will look [14:08] elopio, yes, sounds good :) [14:08] mterry: rsalveti: Please, set your name with the 'whoami' command. [14:08] not sure how to solve that. I did it manually on tarmac. [14:09] I guess we can have a setup command on the plainbox tests? [14:09] elopio, whoami in what context? irc? [14:09] mterry: no, bzr whoami. [14:09] elopio, that is set for me [14:09] needed for the bzr commit that it's done in a couple of plainbox tests. [14:10] mterry: well, yes, on your machine you have it set for sure. But on the builders it's not. [14:10] elopio, I see what you're saying [14:11] elopio, stupid bzr shouldn't error out for that [14:11] or we could just put bzr whoami on the two tests, before bzr commit. [14:11] but i understand why it does [14:11] elopio, yeah easiest is just a quick dumb whoami in the tests [14:11] that way we don't rely on environment being configured right [14:11] mterry: sure. Will you do it or should I? [14:11] elopio, i will [14:12] tx [14:13] 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] 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] not yet :) [14:14] ah just found the examples in the repository - i guess i will get it with those [14:14] (Spreed WebRTC is a go server after all) [14:16] mvo_: where does the software for the plugins come from? [14:17] longsleep: it can be various sources, launchpad, github, the archive, local [14:18] 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] longsleep: are you working on spreedbox? that's nice! [14:19] elopio: yeah i am [14:20] mvo_: ok found it - it downloads it from https://storage.googleapis.com/golang/go1.4.2.linux-amd64.tar.gz [14:21] mvo_: i am not sure if i like that - means builds cannot be automated if the build environment has no internet [14:21] mvo_: i think snapcraft plugins should come from normal deb packages [14:22] mvo_: or rather the third party gear [14:22] longsleep, why ? you could use a pluin (or wrtite one) that only uses debs ... and provide a local mirror [14:22] 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] *plugin [14:22] ah true - i can just provide my own plugins as python modules [14:22] longsleep: snapcraft mandates no policy here, its fine to write plugins that use debs of course [14:22] got it [14:22] 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] well it mandates a policy ... somehow ... "Go Wild !!" [14:23] haha, ok, it does [14:23] * longsleep likes 'wild' a lot [14:24] 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:26] fgimenez: well, only detail is that snappy rolling edge is still not booting on canonistack [14:28] elopio: not booting, or not getting network? [14:28] Chipaca: hard to tell as I have no way to know what's happening. [14:28] it doesn't leave a log. [14:29] elopio: i haven't used canonistack; can't you reset an instance? like, hard reboot it? [14:29] elopio: or, better, can't you connect to a serial console of an instance? [14:29] or even mount the writable partition ? [14:29] from the outside [14:30] Chipaca: I can hard reboot. That's in progress. [14:30] other questions folks: how can i install snaps which are not in the store / say i have them as a .snap file [14:30] or that, although i can't imagine building an api for that :) [14:30] I think the log is what comes from the serial console, maybe? don't really know. [14:30] 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] elopio: if everything is alright :) [14:31] ok, /me waits for it. [14:31] * longsleep just discovered that snappy install somefile.snap seems to work [14:31] there's an abundance of wishful thinking in that, but maybe :) [14:31] longsleep: what do you mean? [14:32] 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] Chipaca: when i built a snap for some software, how do i install it without the store [14:32] Chipaca: just install from file ? [14:32] longsleep: yes [14:33] longsleep: it's called sideloading (your package will have origin: sideload) [14:33] Chipaca: ok thats simple enough then [14:33] Chipaca: all right - can i sideload during image creation in u-d-f as well? [14:34] yeap [14:34] use the --install option [14:35] ok - so just ignore it is in the "Deprecated" section? [14:35] elopio: funny that you bring this up, the integration tests fail if git config isn't set [14:35] longsleep: heya [14:35] longsleep: I'm sorry we didn't manage to finish our exchange [14:35] lool: I didn't see that error, but I suppose it would be the same, yes. [14:35] longsleep: I see you've submitted a snap though :-) how did you end up approaching this? [14:36] lool: no worries i had plenty of distraction here thanks [14:36] longsleep: where in "deprecated"? i see it under "development" here [14:36] elopio: it was failing to me due to EMAIL/GIT_COMMITER_NAME etc. not being set in the test of snapcraft pull [14:37] 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] longsleep: oh I thought you had submitted a spreed snap [14:37] lool: no - not yet [14:37] lool: i did build one though - but that was just hacking around [14:38] lool, we're keeping him busy with re-designing the uboot process [14:38] yeah - but it turned out to be harder for you than it was for me i guess :) [14:38] longsleep: ah there's a dummy spreed snap up for review, lol; I think it's just an empty one though [14:38] lool: Who submitted that ? [14:39] not me [14:39] ogra_: eh, where's that happening? [14:39] lool, in 15.04 [14:39] 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] lool: yes thats too - he sent me the details [14:39] lool, we moved away from txt files and fatwrite to using a binary blob environment file and put everything into variables [14:40] lool: i will try snappcraft first and see how it goes and then submit one next week [14:40] either with snapcraft or manually crafted [14:40] mterry: heya [14:40] lool: do you have some time to discuss the entropy issue? [14:40] longsleep: snapcraft is comign really well; it's already able to deliver quite complex combinations [14:41] longsleep: yes, with pleasure [14:41] 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] lool, hi [14:41] 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:42] mterry: would love to discuss some snapcraft bits when you have some time [14:42] 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] lool, sure [14:42] lool: means any key created on first boot is weak as it was created without entropy. [14:42] longsleep: so what surprizes me is that this must be a common problem; how is this typically solved in other embedded systems? [14:43] lool: it is a common problem yes - with embedded systems and with cloud systems as well [14:43] lool: in embedded systems this is solved by having a HWRNG on chip which which feeds entropy into the kernel [14:44] 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] lool: for this to work, ususally a system service is run (eg rngd or haveged) [14:45] elopio, lool: that doesn't seem to break the tests. is that just for correctness? [14:45] 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] 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] mterry: it broke the tests for me yesterday [14:45] mterry: on a clean vm with no git config [14:45] lool, I saw your branches go by. I can start reviewing them, but did you want to talk about something outside the branches? [14:46] mterry: I had to set the usual env vars (or I could have set git-config) for the tests to pass [14:46] mterry: this broke snapcraft pull on top with the git commit -m 1, -m 2 etc. test [14:46] mterry: topics I've listed above [14:46] mterry: in no particular order [14:46] lool, ok... our buildd managed, but I guess it's a fragile thing [14:47] 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] lool: or host keys for SSHD for that matter [14:47] I'm trying to install from the store and I'm getting "snappy package not found" [14:47] It shows up in "snappy list" though… [14:47] 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] Sorry snappy search [14:47] longsleep: I'm scared by the entropy service in the cloud too; surprized there is no support from vm providers for this [14:48] longsleep: the hardware generators feels like the msot natural [14:48] longsleep: why does this need a daemon rather than the kernel just using it? [14:48] lool: because there can be many sources for random data, and having them all in kernel space would be complicated [14:48] lool: thus it is in user space [14:48] 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:49] lool: see http://linux.die.net/man/8/rngd [14:49] longsleep: makes sense [14:49] lool: yes, the kernel uses some hardware rngs directly [14:49] longsleep: so this seems like a rather core thing that should be there on all linuxes; how come we dont include it? [14:49] mterry: the last topic was some feedback on tarball/copy plugins [14:50] mterry: and the jre/jdk one is one which might need discussion [14:50] lool: well - first of all most people do not care. Second, most PC's do not have a extra RNG hardware [14:50] lool: there are USB dongles and such for it though [14:50] mterry: otherwise, yes, the rest was just a heads up on branches I've pushed [14:50] lool, (I was off yesterday and will be off half today, so I've not had much time to review) [14:51] 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] lool, lay your tarball/copy feedback on me :) [14:51] 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] lool, cool, ACK [14:51] 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:52] mterry: so the copy stuff is too minimal and I find it's clumsy to list the filenames directly as yaml keys [14:52] lool: it should be a decision of the OEM provider how random is best created for this particular hardware [14:52] mterry: I wanted to copy a dir over and couldn't, I wanted to do a shell glob and couldn't [14:52] lool, you should be able to copy a dir over.... that's intended and (I thought) tested [14:52]