Jurij Smakov: Broken envelope-from considered harmful

=debian-x
mailbox.
Debian XSF News #1
mesa 7.9
was uploaded to experimental
by Julien Cristau.xserver-xorg-sun*
drivers to experimental
for us.mrconfig
file to ease downloading/updating all XSF packages,
thanks to the mr tool, and
some bits of documentation. I also
added the git URL
to the upstream repositories to debian/watch*
for all packages.DRI
, and unfortunately, I
haven t digged into mesa
yet, but thankfully we had some answers
from upstream there.xfonts-*
packages, prepared by Julien Cristau.x11-*
bundles as well. Why are we creating
bundles? Because there are many tiny applications, which (from the
distribution point of view) don t deserve their own package. For
example x11-apps
contains toys like xclock
, xeyes
, or
xlogo
.lib*
packages, plus pixman
. When there were no
fundamental changes (as in: no need for an shlibs
bump, which
could prevent some packages from migrating), those were uploaded to
unstable
, others went to experimental
.libx11
, from a stable
branch. The
2:1.3.3-4
version
has been unblocked for squeeze,
and brings support for
Compose O A
and for
Compose \ o /
.apple:badmap
and
apple:goodmap
options for macintosh
keyboards in
xkeyboard-configuration
(which produces the xkb-data
binary
package), thanks to a
bugreport from Yves-Alexis Perez;
it s been unblocked for squeeze as
well. If someone notices an inversion of those keys after the
upgrade, that s probably because one of those options was added at
some point, was ignored and unnoticed, and finally taken into
account. Depending on the case, it s sufficient to switch to the
other one, or to remove it entirely.experimental
.xserver-xorg-video-mga
user (Ferenc W gner), we were
able to extract and apply a patch from
launchpad s #292214
to fix the dual head
breakage. Since we haven t seen any complains since then, we ll
probably ask for an unblock for squeeze
.RC1
for
X11R7.6
and it d be nice to keep it that way, but that requires time/work.udev
logging in /etc/udev/udev.conf
I've found lots and lots of messages like this in the log:
Dec 18 00:41:46 droopy udevd-work[425]: wait for '/sys/some/path/bInterfaceProtocol' for 20 mseconds
The only udev
rule file containing a reference to
bInterfaceProtocol
was /etc/udev/rules.d/z60_libccid.rules
with the following lines in it:
# last file created by the kernel, if this is present everything should be
WAIT_FOR_SYSFS="bInterfaceProtocol"
The libccid
package itself is long gone (I don't remember installing
it at all), and the versions of the package starting with 1.3.4-1 (uploaded in
February 2008) do not contain this rule. However, the file survived on my
system, so this rule was continuing to trigger for every device, even the ones
not providing the bInterfaceProtocol
at all. Removing the now-redundant
file resulted in a dramatic boot speedup (it now takes about 30 seconds), so if
you are experiencing similar problems, you might want to check it out.
NewGlobalRef
on it, to avoid garbage collection on exit from a native function. I did that, however I only had access to the class, and Android JNI only supports calling NewGlobalRef
on an object, so I had to create a dummy object in the native code (JNI_OnLoad()
function, actually) and cache that.
5. That finally enabled me to call into Java from native, attached threads (w00t!). Unfortunately, you are not allowed to modify the UI (exactly what I wanted to do from my Java callback!) from a non-UI thread, which brought me right back to the drawing board.
6. As callbacks initiated from native code would not work for this reason, it was suggested to me to use a classic producer-consumer mechanism, getting Java call into the native library block until new information gets delivered by a native thread. Easily done with some pthread mutexes, and the goal is close, right?
7. Wrong! Now the problem was that if I started a UI Java thread, which would call the native function in a loop to retrieve the data (it would not actually spin, as the native function blocks until new data is available), then it would be declared not responding by the UI framework in a few seconds. I could start a non-UI thread for that, but you guessed it a non-UI thread is not allowed to update UI! Instead of resolving the problem we just shifted it into the Java land.
8. While I was simply thinking about stuffing the result into a class variable and passing it to the UI thread this way, this tutorial, showing how to display a progress indicator while doing some heavy calculations in the background, provided a more elegant idea. One can use Android s android.os.Handler
class to pass messages (with arbitrary payload) between threads.
That was the last piece of the puzzle, which allowed me to finally achieve a working implementation (some 10 hours or so later :-).
Next.