Opened 15 years ago

Closed 15 years ago

Last modified 14 years ago

#105 closed defect (fixed)

SoaS should include the software update control panel

Reported by: cjb Owned by: bernie
Priority: Normal Milestone: Unspecified
Component: Sugar on a Stick (SoaS) Version: Git as of bugdate
Severity: Major Keywords: community-request
Cc: sdz, erikos Distribution/OS: Unspecified
Bug Status: New

Description (last modified by erikos)

.. 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.

Change History (20)

comment:1 Changed 15 years ago by marcopg

  • Bug Status set to New
  • Component changed from SoaS to sugar
  • Distribution/OS set to Fedora
  • Milestone set to 0.84
  • Severity set to Major
  • Version set to 0.83.x

Reassigning to Sugar because I want to solve this upstream.

comment:2 Changed 15 years ago by walter

  • Keywords community-request added

comment:3 Changed 15 years ago by erikos

  • Milestone changed from 0.84 to 0.86
  • Owner changed from marcopg to bernie
  • Status changed from new to assigned

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.

comment:4 Changed 15 years ago by bernie

We already have sugar-update-control in rawhide.

comment:5 Changed 15 years ago by sdz

  • Cc sdz added

comment:6 Changed 15 years ago by erikos

  • Component changed from sugar to SoaS
  • Description modified (diff)
  • Milestone 0.86 deleted
  • Version 0.83.x deleted

comment:7 follow-up: Changed 15 years ago by bernie

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

comment:8 in reply to: ↑ 7 Changed 15 years ago by bernie

  • Cc erikos added

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?

comment:9 Changed 15 years ago by erikos

We did decide yesterday to not include it.

comment:10 Changed 15 years ago by sdz

  • Distribution/OS changed from Fedora to SoaS
  • Milestone set to soas_linuxtag
  • Priority changed from major to Urgent
  • Version set to Git as of bugdate

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.

comment:11 Changed 15 years ago by 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?

comment:12 Changed 15 years ago by 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/", line 315, in __select_option_cb
  File "/usr/lib/python2.6/site-packages/jarabe/controlpanel/", line 205, in show_section_view
    globals(), locals(), ['view']) 
  File "/usr/share/sugar/extensions/cpsection/updater/", line 23, in <module>
    import bitfrost.update.actutils as actutils
ImportError: No module named bitfrost.update.actutils

comment:13 Changed 15 years ago by cjb

ImportError: No module named bitfrost.update.actutils

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

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

comment:14 Changed 15 years ago by sdz

  • Milestone changed from soas_linuxtag to Unspecified by Release Team
  • Priority changed from Urgent to Normal

moving to our general milestone.

comment:15 Changed 15 years ago by CarolineM


This is no longer expected to be done in June?

What needs to happen to get this working?


comment:16 Changed 15 years ago by 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?

comment:17 Changed 15 years ago by 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 for Activity version information and downloads.
3). Extend 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)."

comment:18 Changed 15 years ago by 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.

comment:19 Changed 15 years ago by tomeu

  • Resolution set to fixed
  • Status changed from assigned to closed

The activity updater has been moved into Sugar.

comment:20 Changed 14 years ago by sascha_silbe

  • Distribution/OS changed from SoaS to Unspecified

Bulk change distribution=SoaS -> component=SoaS

Note: See TracTickets for help on using tickets.