[Debian-olpc-devel] Sugar 0.88

[Jonas Smedegaard]

On Wed, Mar 31, 2010 at 05:18:13PM +0200, Sascha Silbe wrote:
>On Wed, Mar 31, 2010 at 09:05:52AM +0200, Jonas Smedegaard wrote:
>
>>Yeah, I noticed too that different things are shipped in Git and in 
>>final tarballs - not only PO files but autogen.sh also gets stripped.
>The PO files getting stripped was a mistake - they got dropped out from 
>some auto* setting (the actual mistake) and thus were not included in 
>the source tarball (generated using some auto* rule) anymore.

Ok. I do not dispute that PO file handling have been improved - just 
extended to talk about other files being similarly problematic seen from 
a distributor POV, regardless of possibly being rooted differently.


>>Packaging would probably be simpler to automate reliably if upstream 
>>never *stripped* files when making tarballs from Git (except the very 
>>Git-specific .git/ and .gitignore), only *added* autogenerated files 
>>(and not too much of that either - run "make distclean" too!).
>AFAICT Sugar is relying on the usual auto* magic. Do you think there's 
>anything wrong with our setup, or should we do something beyond what 
>auto* usually does?

I believe you should register all files part of your project with the 
autotools mechanisms, so that the output "make dist" is identical to the 
content of the Git - except for .gitignore files and the .git dir.

Commonly an "autogen.sh" file is maintained in Git but stripped from the 
released tarballs.

For that particular file I actually recommend _against_ distributing it 
but instead drop it from Git too, and educate the developers to use the 
autotools "autoreconf" tool instead of shipping a script for same 
purpose.


>>>I updated Glucose with packages from that repo (using https - 
>>>thanks!). Now Sugar fails to start up: some KeyError with NoneType 
>>>being used in layout-related code. Will investigate tomorrow.
>OK, got it narrowed down. As I suspected, it's gconf returning None 
>(for /desktop/sugar/desktop/favorites_layout). Now we get to the 
>point where my gconf experience is lacking:
>/usr/share/gconf/schemas/sugar.schemas contains a default setting 
>("ring-layout"), but this doesn't get applied. In fact gconftool-2 
>never reads any .schemas file, only 
>/var/lib/gconf/defaults/%gconf-tree.xml. The latter file contains 
>several "directories" for for /desktop/sugar/..., but no "entries" 
>whereas it has lots of entries for /apps/metacity/....
>
>This is on a fresh debootstrap'ed installation of Debian Squeeze that 
>only ever has seen the current Sugar packages from Squeeze and your 
>newly packaged ones. Except for starting up Sugar and changing views, 
>it hasn't been used in any way (because there are no activities).
>
>Where it gets interesting is that I still have the chroot I used for 
>creating the installation - and there the defaults file contains all 
>the /desktop/sugar/... entries! The recorded "mtime" of the entries 
>is that of the upgrade from the Sugar packages in Squeeze to the ones 
>from your repo.
>The only difference between the two copies is that I've installed a 
>few more packages on the "real" one, booted it, started up Sugar on 
>it and installed your packages at a different time.
>
>Can you make any sense out of this? Some gconf tool being called 
>during package upgrade failed to do its job perhaps?

Perhaps Dbus communicate on localhost (not a socket) and thus "leak" 
outside of the chroot.

But I cannot help debugging such problems - I am not clever with Dbus.

If you can reproduce the problem in "plain" (i.e. non-chroot'ed) 
environment then please file a bugreport!


>>>>Browse packaged now, and tested that it works with 0.88 libs!
>>>I don't see sugar-browse-activity-0.88 in the above repo. Is it  
>>>somewhere else?
>>You should install sugar-browse-activity-0.86, even for 0.88.
>Ah, that works now, thanks!
>
>Not sure whether it matters, but I encountered this output during 
>installation (inside the chroot):
>
>Setting up xulrunner-1.9.1 (1.9.1.8-5) ...
>Obtaining the module object from Python failed.
>
><type 'exceptions.ImportError'>: No module named xpcom.server
>Obtaining the module object from Python failed.
>
><type 'exceptions.ImportError'>: No module named xpcom.server

Please file a bugreport about it.  Might just hang there (as I have no 
clue what it is or if it is important), but might help others searching 
for this issue too.



  - Jonas

-- 
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-olpc-devel/attachments/20100331/c68222cc/attachment.pgp>