Fix Kano Burners in OSX

[alex5imon]

We need to make sure Kano Burners work in the following OSX versions:

• 10.6
• 10.7 (Problems with burner in Mac OS 10.7.5 #21)
• 10.8
• 10.9
• 10.10

[alex5imon]

@gerito1 thanks for the work on this!

We had a pull request pending for a while #25, that aims to fix this problem. Here is the latest comment

[gerito1]

@alex5imon Sorry I didn't read that bug report.
I was pointing that to anyone that could be interested to fix this, because I struggled with it working on windows. Unfortunately I had no access to an OSX machine with sd card reader, so I won't work on this. This was a just notice.

[zmingee]

I found this issue on BountySource. If the issue is still present, I'm willing to take a look at it. Same goes for #32 if it's still an issue as well. Just say the word and I'll start digging!

[zmingee]

Actually, I went ahead and tested it on my MBP (10.10.2) and it failed. Was stuck at "Downloading Kano OS..." for about 20 minutes, and then failed.

So, I suppose that means it doesn't work. I'm going to go ahead and start working on the issue. I'll log any progress I make against this thread.

[zmingee]

After doing more testing on 10.10.2, it seems that the issue I was having before was just intermittent. I can't replicate the issue anymore. I'm going to go ahead and test the app against 10.6 - 10.10. When I run into any issues, I'll log them against this thread as well. Invariably, I'll run into #21. I'll work on that issue when I have the virtual environment setup for 10.7.

If you have any applicable information, just pass it along to me when you get a chance.

[gerito1]

@zmingee
The structure of os_info['filename'] has changed with the last commit.
Edited: As returned by the download.
In the osx branch of burn_kano_os, remember to append ".gz" to the filename, otherwise your burn process will fail to find the compressed file.
In the current version os_info['filename'] = "Kanux-xxx**.img**", you need "Kanux-xxx.img**.gz**"

[zmingee]

Actually, my machine successfully burned the image. I do see what you're saying though.. The URL http://downloads.kano.me/public/latest.json shows "filename": "Kanux-Beta-v1.3.2-release.img", and src/common/download.py shows the following...

src/common/download.py

def get_latest_os_info():
    debugger("Downloading latest OS information")

    # we put everything in a try block as urlopen raises URLError
    try:
        # get latest.json from download.kano.me
        response = urllib2.urlopen(LATEST_OS_INFO_URL)
        latest_json = json.load(response)

        # give the server some time to breathe between requests
        debugger('Latest Kano OS image is {}'.format(latest_json['filename']))
        time.sleep(1)

        image_url = '{base_url}{filename}'.format(
            base_url=latest_json['base_url'],
            filename=latest_json['filename'])

        gz_url = '{image_url}.gz'.format(image_url=image_url)

        # use the url for the latest os version to get info about the image
        image_info_json = '{image_url}.json'.format(image_url=image_url)
        response = urllib2.urlopen(image_info_json)
        os_json = json.load(response)

        # give the server some time to breathe between requests
        time.sleep(1)

    except:
        debugger('[ERROR] Downloading OS info failed')
        return None

    # merge the two jsons, add derived values and return a single info dict
    os_info = dict(latest_json.items() + os_json.items() +
                   [
                       ('image_url', image_url),
                       ('url', gz_url)
                   ])

     return os_info

Nowhere in this block does it change the value for os_info['filename']. download_kano_os does not change the value, and neither does kano-burner. It just passes the dict to start_burn_process. Once it's there, the following is ran...

src/osx/burn.py

def start_burn_process(path, os_info, disk, report_progress_ui):

...

    burn_thread = threading.Thread(target=burn_kano_os,
                                   args=(path + os_info['filename'], disk,
                                         os_info['uncompressed_size'], thread_output,
                                         report_progress_ui))

...

def burn_kano_os(path, disk, size, return_queue, report_progress_ui):
    cmd = 'gzip -dc {} | dd of={} bs=4m'.format(path, disk)

...

I can't see anywhere that it actually appends ".gz" to the filename, but the burn is definitely successful.

Do you have any idea what's going on there?

[gerito1]

@zmingee Yeah you are right. The filename didn't change. They changed the latest.json.
There the 'filename' key reflect the filename of the image itself, not the compressed file.
The contributor that changed the json structure, didn't reply me about this specific issue.
I proposed add the compressed_filename to the os_info dictionary returned by the download. 'Cause in windows if it is a compressed file, 7zip will deal with it, but again no reply.
Just be aware of that.
If you need append '.gz' for now. I don't know what to say. :(

[zmingee]

Actually, I tested it manually and if you run "gzip -dc " without the .gz extension, it still recognizes the file. It doesn't throw a "file not found" error. So, I believe that's why it works correctly.

Regardless, tomorrow I'll test the app against 10.6 - 10.10 and see what errors I run into.

[gerito1]

@zmingee Wow, interesting. That solves many things for me.
So gz it's smart enough to discover that kind of things.
Well 7zip does not have any way to infers that though. It's good to know.

[alex5imon]

@zmingee have you done any more testing in OSX after the changes submitted here: 9cd5569?

[zmingee]

Yes, that's the version I've been doing my testing on. So far, Yosemite and Mavericks works fine. I think the initial issues I was having were non-related. Still need to test the others OSes, which I planned on doing this weekend.

[alex5imon]

@zmingee great!

[zmingee]

I'll keep you posted over the weekend, @alex5imon

[Ealdwulf]

@rluz @FMog A version for testing can be found in http://dev.kano.me/temp/Kano%20Burner%20OSx%20v2%20rc280415%2009d1be8.dmg

The following should be fixed in this version:
#29 #28 #22 #21 #20 #19 #12 #9

[Ealdwulf]

@FMog @rluz I'm assigning this to Megan, but actually I don't know how the burner testing is supposed to be split between the two of you.

I'm going to add some more information about testing in a bit...

[rluz]

@Ealdwulf Cool, I can test it on Macbook Air 2014 Mac OS X 10.10 and 10.9 / White Macbook 2009 with third party SD card reader Mac OS x 10.8 and 10.7.
All 64 bit OS.
I can also test it on the office iMac 27 inch 10.10.

[Ealdwulf]

Okay, @rluz I assigned it to you. Similarly to the other ticket, ideally it should be tested without python being installed.

[Ealdwulf]

@FMog @rluz I added some more information to the other tickets .

I have added an extra feature to the burner which allows it to be pointed at a different server/image.
This can allow:

• using a smaller image (for testing UI and other stuff where you don't need to wait for the whole image to download
• testing against a server under your control (eg for more complicated testing against

Eg, from a terminal run

KANO_BURNER_TEST_URL=http://dev.kano.me/temp/burner_test.json open "/path/to/Kano Burner.app"

For comparison the normal json is http://downloads.kano.me/public/latest.json
The above one is a 10Mb test image containing random junk.

[monaka]

I found this issue via Bountysource. Is the bounty still active?

[alex5imon]

It's not active anymore sorry

[ulgens]

@alex5imon Why didn't anyone close it then? :) It's open on both Github and Bountysource.