Hi there, == Meeting ==
We had our weekly IRC meeting the 25th; see: <https://wiki.ubuntu.com/MobileTeam/Meeting/2008/20080925> Mootbot log/minutes not yet available, bot owner pinged. Only irclogs.ubuntu.com for now: <http://irclogs.ubuntu.com/2008/09/25/%23ubuntu-meeting.html> Present: davidm, StevenK, persia, ogra, lool, Burgundavia == Activity reports == === Steve Kowalik === * Hack on mid-launcher, trying to get it to start directly. Get kicked around by hildon-desktop. [3h] * Investigate if I need one or two uploads of hildon-desktop. Two. Sigh. [2h] * At Loic's request, see if I can rip libhildonfm out of hildon-desktop's grasp. Manage to do so. Test what's in bzr, find it doesn't break and upload it. [4h] * Clean up python-hildondesktop and kourou (the new name of mid-launcher), pushing bzr branches, uploading and NEWing them. [5h] * Update the seeds, and hildon-desktop for moving from mobile-basic-flash to kourou. [1h] * Belt hildon-desktop more, at Loic's request, so that hildonfm support can be disabled. [1h] * Look at fixing ivman, throw a diff at Loic, and have him throw it back as terrible, and discuss different solutions. [1:30h] * Investigate using nautilus as our file manager. Manage to hack together an image for it. Notice that Nautilus looks cramped even on a Q1. [3h] * Release a new version of kourou, fixing an initialisation bug, and only showing .desktop entries that are Type=Application. [2h] * Organise flights to FossCamp/UDS. * Some NBS work. === Emmet Hikory === ==== Mobile ==== * Reading about preseeding partman-auto * Registered a spec for MID installer * review & comments on kourou and python-hildondesktop * troubleshooting and advice on XDG handling * investigation on missing linux-lpia-meta (kernel failed to install) * reproduction and investigation of the grub-failed-to-install issue === Loïc Minier === This report covers two calendar weeks but actually a week worth of work as I was at the OSIM World and Maemo Summit events. ==== Misc ==== * Reviewed Ekiga snapshot; it was unfortunately quite broken, but most issues had already been fixed or were fixed subsequently; need to retest final 3.0, especially if we want it for intrepid. Didn't try out the lpia version. * Poked acpid; couldn't resist rewriting its init script; not pushed yet though; ended up working on an Ubuntu upload with james_w by pure coincidence * Misc GNOME-ish uploads, pango, poppler, glib etc. * Misc intrepid work/help, FTBFS and the like * Some sponsoring/mentoring * Finished packaging of the core elisa 0.5.x packages; because elisa is such a python import hub and the 0.3 -> 0.5 diff was massive, I had to write tools to search for python imports and corresponding packages; my scripts are currently awful, but use decent a approach: - first tool tries to parse all *.py files into ast trees, then recurses the tree to find import statements and outputs packages/modules - second tool tries to "half-load" said modules (with "imp") to tell what while they come from; the real builtin modules are detected; this tool needs to be told about private modules/extensions and needs the modules installed of course, but it doesn't need a X DISPLAY or the hardware to actually import the modules; this outputs list of pathnames which are easily mapped to pacakges Currently, everything is very manual, I run tool one and two on some trees I care about, for instance debian/packagename or usr/lib/somepkg/someplugin/**/*.py, and manually fix errors or do some adjustments when it gets to list packages. I believe this could all be incorporated in a new set of python dependencies tools, but the second tool would likely use maintainer-provided data similar to shlibs. I wouldn't want to show my current code to do this, but what it mostly misses is a good command-line frontend and overrides at some levels. It also doesn't support files mixing line endings for some reason (python compiles them fine though?!), and some modules remain tricky to handle (e.g. os.path). I'd need maps to say something like "these imports can be ignored, these should be mapped to recommends, and these to suggests, the rest to depends"; these maps need to be per source file, or perhaps even with line number (I doubt this is terribly robust though, but info is available). Of course, Python allows dynamic imports, optional imports, imports from C code etc., but this covers the largest part and helped me tremenduously identify imports. I reported a bunch of bogus relative imports or module priority mismatches to upstream as a result (like some plugins using now bogus imports, plugins from base calling into plugins from good etc.) and more. I wish someone has time to implement such tools in a way suitable for all .deb packages' maintainers to use! Bye -- Loïc Minier -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile