Some scripts use wrong hostapd.conf path

[alext-mkrs]

On the current image, the configure_edison script uses a wrong path. The file is actually /etc/hostapd.conf, but it tries to use /etc/hostapd/hostapd.conf. Probably an artifact of an older hostapd version that was shipped with original Edison image and needs to be fixed.

ADDED LATER: oh, and meta-intel-edison/meta-intel-edison-distro/recipes-core/post-install does that as well.

[alext-mkrs]

Okay, this won't be as easy - the recipe is meta-intel-edison/meta-intel-edison-distro/recipes-support/oobe and it refers to an external repo: https://github.com/01org/edison-oobe, which is not a major problem to override/patch, but this opens up a topic we've discussed with @htot a while ago, on having our own copies of all dependencies, so that we can preserve/manage them. Looks like this is one more such thing.

@htot, how about creating a copy of this one as well and getting back to our other discussion about moving this out of your personal account to an "organization"? That way we both could have an ability to create repos and I could take care of such things by myself. This should be fairly simple and I can handle it all by myself (create, setup permissions for us both, move repos and update the recipe references) - let's just agree on that being the direction.

[htot]

Yeah, I think I already mentioned the postinstall script. Forgot about oobe (actually never realized what the acronym stood for until now).

It's a good idea to create an organisation. So how do I do that? I see. What name shall we choose? intel-edison, or do you want it more general intel-makers, intel-gems or so?

[alext-mkrs]

As organizations are free, I'd propose just a targeted "edison-fw" or "edison-os" to avoid using "intel", to prevent confusion with official repos (and any potential trademark/attribution/endorsement legal problems). Both are unused. And honestly - I believe it almost doesn't matter :) if the contents is good, people will use it anyway, linking is cheap these days and no one remembers full URLs probably anyway.

I'd go with "edison-fw", as IMHO a more generic term, as FW covers both OS and bootloader (and any potential additional stuff we might gather there). Any objections?

[htot]

I wanted to create right now edison-fw but is already taken.

[alext-mkrs]

Yeah, I went ahead and created it right after the post. I propose a single person (me - describing how to do that will take me longer than doing :) does the initial setup, to avoid misunderstanding and stomping on each other's feet. I'll set us both as owners, but the initial stuff is simply imho more effectively done by one person.

[htot]

That's great thanks. I did already find out howto and created intel-edison :-) But this fine. I think you need to 'invite' me, and I need to transfer the repo(s)?

[alext-mkrs]

Yep, I've just sent an invitation. And yes, transferring repos to be owned by the org will be the fastest way and will allow you to start using the typical GH approach of having a fork of the main repo as the sandbox, makes it IMHO easier to experiment, otherwise you need to do that on branches. After transfer we'll need to update the build scripts and git SRC_URLs here and there, but I can do that - just let me know when done changing the ownership.

[alext-mkrs]

I initially thought to create a repo copy and then yours could be just deleted, but that's probably too much hassle anyway, we don't have any need to keep everything online every second, so short period of "repo in new org but links in recipes point to old location" is perfectly acceptable.

[alext-mkrs]

Let me continue hijacking this issue for repo migration for now (I'll probably just delete all these irrelevant comments afterwards, as there's no real value in preserving them).

@htot, I see you've moved the meta-intel-edison repo but not other ones so far - do you need any help with the rest, or something (though only you'd have permissions for changing ownership)? If you just don't have time for that right now - I'm absolutely fine with that, just want to sync up on what your plans are.

[htot]

@alext-mkrs just wanted confirmation that it's ok like this (you must have missed my question). Transferred linux, u-boot, meta-acpi now, I think that's all we need? There is a edison-linux which has a -rt kernel (3.10.17), but I don't think it's worth to go back that far to fix up the dizzy branches. OTOH if you say let's do it, I'll transfer that one too. Mraa and meta-intel-iot-middleware are not needed any more I think.

[alext-mkrs]

Yes, I must have missed it, sorry. Yes, meta-intel-edison looked good to me. I can double-check the rest in the evening today (and see what other repos might be needed), but basically GH simply moves the repo as-is, with all the code, issues and PRs, so it should be ok. The list you mentioned looks reasonable to me and I'll double-check if we by chance don't have anything else used. Probaly just a grep with your GH account name (part of the URL) would suffice.

[alext-mkrs]

Ok, the current set of repos looks good to me. I've run out of time today, but I'll go for updating recipe links over the weekend. Thanks for moving the repos.

[htot]

No prob. In the meanwhile I'm gonna try a few things to see if I can solve hsu problems on 64b. And work to solve issue https://github.com/edison-fw/meta-intel-edison/issues/12 (move docs to /docs directory). Currently I have this repo https://github.com/htot/test, which generates https://htot.github.io/test/. This still needs a bit of work, and I can't seem to get gh to build the site. So I build it locally and pushed all including the generated site.

[alext-mkrs]

So I'll remove all the org-related comments tomorrow unless you think they are worth preserving. Just to clean this issue up.

[htot]

No problem. I'll start building your PR this evening.