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
