SoaS should include the software update control panel

[cjb]

.. cause otherwise updating activities is not as much fun. You can install activities from activities.s.o and when you install a newer activity it replaces the previous one.

The main issue is that one gets no notification when a new version is available.

[marcopg]

Reassigning to Sugar because I want to solve this upstream.

[erikos]

I think that it's too late to do #105 for 0.84 properly in upstream. If it's important for a deployer, it will need to be taken care of later when they do their customizations. And hope it will be ready for F12 (as upstream)

I think Bernie was once interested in this.

[bernie]

We already have sugar-update-control in rawhide.

[bernie]

Can we add the sugar-update-control rpm to the soas image now, or do we wait until the next deadline?

[bernie]

Replying to bernie:

Can we add the sugar-update-control rpm to the soas image now,
or do we wait until the next deadline?

Erikos? What do you think?

[erikos]

We did decide yesterday to not include it.

[sdz]

This has been included in the latest snapshots, but fails to work due to some error related to bitfrost. It's absolutely important to get this included in time in SoaS, so I'm raising priority here.

[cjb]

The bitfrost.* libraries are present in the GIT tree for the update control panel, so I don't understand what the problem is. Maybe the RPM was mispackaged to not include them, or maybe something else is wrong?

[sdz]

Okay, I've reproduced this, so here's the traceback. It would be cool to get this fixed soonish, as it's something we've on our roadmap for the SoaS RC release in June.

KeyError: 'uid'
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/jarabe/controlpanel/gui.py", line 315, in __select_option_cb
    self.show_section_view(option)
  File "/usr/lib/python2.6/site-packages/jarabe/controlpanel/gui.py", line 205, in show_section_view
    globals(), locals(), ['view']) 
  File "/usr/share/sugar/extensions/cpsection/updater/view.py", line 23, in <module>
    import bitfrost.update.actutils as actutils
ImportError: No module named bitfrost.update.actutils

[cjb]

ImportError: No module named bitfrost.update.actutils

bitfrost.update.actutils is clearly present in the GIT tree:

​http://dev.laptop.org/git/users/cscott/sugar-update-control/tree/bitfrost/update

So, I think the RPM has been mispackaged, and needs to be remade with all of the files in.

[sdz]

moving to our general milestone.

[CarolineM]

Hi,

This is no longer expected to be done in June?

What needs to happen to get this working?

thanks,

[CarolineM]

also, I'm talking to DaveB and realizing that I really don't understand this thoroughly.

What will be possible once this ticket is complete?

What the plan for maintaining in the field both Sugar and Activities, when Sugar is on a Stick or on any machine that isn't a XO?

[garycmartin]

Coming in from the sidelines here, but my understanding is that sugar-update-control was only ever intended as mechanism for keeping already installed Activities easily up-to date. It then gained (a point of some contention) the ability to install a whole collection/pack of Activities like the G1G1 or Peru set. This seems to have been an attempt to solve 1). the issue caused when all Activities were dropped from the base Sugar install image and everyone was swamped with "I have an empty home view with no Activities, how do I get them back?" support calls; 2), and the versioning rabbit-hole for specific deployments who could have different Activity version requirements and OS builds, relative to the official releases.

I don't know what's been done so far other than to try and make the sugar-update-control code run in the new Sugar and distro environments/platform; but to be useful, the process would need to:

1). understand the qwerky directory layout and file permission issues created by the Soas distro – it needs to know what it can actually upgrade and where it lives (needs to be every Activity in my opinion, I can easily see needing to download a bug fix version of a core Activity like Browse at some point in a Soas release life cycle).
2). Contact activities.sugarlabs.org for Activity version information and downloads.
3). Extend activities.sugarlabs.org so it generates the microformat xml that was designed for the sugar-update-control process

Regarding the maintaining of Sugar and the underlying distro components in the field, I've not seen too much discussion of upgradability or an upgrade procedure yet. I assume quite a bit of this low level stuff is suited to existing distro procedures (yum/aptitude/...) which could potentially be given a separate graphical UI. I guess for a major version upgrade, if backup is working well (data-store, all user preferences, and likely some other identity/misc items), this could be close to "backup -> make fresh Soas -> restore (-> upgrade to latest Activities)."

[bernie]

The sugar-update-control RPM is now fixed in Fedora. We could enable it in SoaS.

We'd still need to patch aslo to generate the required microformat tags automatically in the activity pages. Meanwhile, activity authors could keep using the wiki (actually any HTML page) as their update URLs.

[tomeu]

The activity updater has been moved into Sugar.

[sascha_silbe]

Bulk change distribution=SoaS -> component=SoaS