Re: [fonc] Communicating with Aliens Problem
On Sun, 6 Apr 2014 22:01:03 -0400, Shawn Vincent wrote: I am very interested in learning more about the state of the art in the communicating with aliens problem mentioned here and other places. What techniques have been developed or considered for this? Greetings from another lurker. I somehow mostly missed the previous discussion here on this topic. (Now I look, 90% glue code is a good summary of the status quo; will revisit that thread soon.) Anyway... ... I did write a PhD thesis about some work in this area: linking software that doesn't have matched interfaces. Note that there's nothing distributed about this work. Sadly it's not a great thesis by any means; I don't want to build it up. But if you wanted to read something not too long, there was an OOPSLA paper in 2010 (that would be delighted to have somebody read it :-). http://dx.doi.org/10.1145/1869459.1869487 (or Google me for a non-paywalled copy, or for the thesis...). I had/have a whole raft of follow-up work that I would like to do. In short, declaratively specifying your glue is the first step towards generating it automatically. There's a lot that could be done. Sadly this whole area seems too cold to get research funding by any means I know right now. Stephen ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[TYPES/announce] Final CfP: Software Composition (SC) 2013 (deadline extended)
[ The Types Forum (announcements only), http://lists.seas.upenn.edu/mailman/listinfo/types-announce ] [Type systems feature prominently in various approaches to software composition. Therefore, the following call for papers may be of interest to many list members. Please note the extended deadline.] 12th International Conference on Software Composition (SC 2013) June 19--20 2013, Budapest, Hungary http://sc2013.ec-spride.de/ Extended Deadline -- Important Dates: Abstract submission: *** January 25, 2013 (now *mandatory*) Paper submission:*** February 1, 2013 (23:59 anywhere on Earth) The International Conference on Software Composition (SC) is the leading venue that addresses challenges of how composition of software parts may be used to build and maintain large software systems. Software Composition 2013 will be the 12th edition in the series, and we invite researchers and practitioners to submit high-quality papers. Submissions that relate theory and practice of software composition are particularly welcome. Software Composition 2013 takes place in Budapest on June 19--20 2013, as part of the STAF 2013 Federated Conferences (spanning June 17--21). Topics of Interest: The SC 2013 program committee seeks original, high-quality papers related to software composition, including but not limited to the following topics: * Component-based software engineering * Composition and adaptation techniques * Composition algebras, calculi and type systems * Feature-oriented software development * Aspect-oriented software development * Model-driven composition * Models of computation * Verification, validation and testing * Dynamic composition and reconfiguration * Large-scale component-based systems * Cloud, service-oriented architectures * Business process orchestration * Visual composition environments * Performance optimization of composite systems We solicit high-quality submissions on research results and/or experience (up to 16 pages, LNCS format, including bibliography and figures) describing a technical contribution in depth. Short and position papers are also welcome for the work in progress session (up to 8 pages, LNCS format, including bibliography and figures). Short submissions must concisely capture ongoing work, new ideas, and experiences. Submitted papers will be judged on the basis of significance, relevance, correctness, originality, and clarity. Submitted papers must be unpublished and not submitted for publication elsewhere. As in previous years, the proceedings of the conference will be published as a volume in Springer's Lecture Notes in Computer Science. Conference Web Site: http://sc2013.ec-spride.de/ Important Dates: Abstract submission: *** January 25, 2013 (now *mandatory*) Paper submission:*** February 1, 2013 (23:59 anywhere on Earth) Acceptance notification: March 10, 2013 Camera-ready copy: March 22, 2013 Conference: June 19--20, 2013 General Chair: Welf Löwe, Linnaeus University, Sweden Program Chairs: Walter Binder, University of Lugano, Switzerland Eric Bodden, Technische Universität Darmstadt, Germany Publicity Chair: Stephen Kell, University of Lugano, Switzerland Program Committee: Danilo Ansaloni, University of Lugano, Switzerland Sven Apel, University of Passau, Germany Olivier Barais, University of Rennes 1, France Alexandre Bergel, University of Chile, Chile Domenico Bianculli, University of Luxembourg, Luxembourg Daniele Bonetta, University of Lugano, Switzerland Lubomír Bulej, Charles University, Czech Republic Shigeru Chiba, University of Tokyo, Japan Ion Constantinescu, Google, USA Schahram Dustdar, Vienna University of Technology, Austria Erik Ernst, University of Aarhus, Denmark Bernd Freisleben, University of Marburg, Germany Thomas Gschwind, IBM Zurich Research Lab, Switzerland Michael Haupt, Oracle Labs, Germany Christian Kästner, Carnegie Mellon University, USA Doug Lea, State University of New York at Oswego, USA Karl Lieberherr, Northeastern University, USA David Lorenz, The Open University, Israel Hidehiko Masuhara, University of Tokyo, Japan Oscar Nierstrasz, University of Bern, Switzerland Jacques Noyé, Ecole des Mines de Nantes, France Ina Schaefer, Technische Universität Braunschweig, Germany Andreas Sewe, Technische Universität Darmstadt, Germany Mario Südholt, Ecole des Mines de Nantes, France Clemens Szyperski, Microsoft Research, USA Immanuel Trummer, EPFL, Switzerland Alex Villazón, Universidad Privada Boliviana, Bolivia Eric Wohlstadter, University of British Columbia, Canada Thomas Würthinger, Oracle Labs, Austria Cheng Zhang, Shanghai Jiao Tong University, China
[Bug 1008553] [NEW] startkde deletes custom plasma-desktop.desktop file
Public bug reported: I use a customised configuration for running KDE. In particular, I use fvwm as the window manager, and disable plasma-desktop by creating my own plasma-desktop.desktop file in ~/.config/autostart, which is just a copy of the one in /usr/share/autostart with Hidden=true added to it. On earlier versions of Ubuntu (up to natty, at least) this had the effect I wanted: plasma-desktop would not start up, and I could use fvwm's desktop furniture instead. I'm now re-creating this setup on a precise (12.04 LTS) install, and find that plasma-desktop not only starts when I thought I'd disabled it, but somehow, my plasma-desktop.desktop file is deleted. A bit of digging reveals the problem to be lines 381--400 of /usr/bin/startkde (from kde- workspace-bin 4:4.8.2a-0ubuntu4). # Added by Debian to fix bug #584905. # Reset user plasma-desktop/plasma-netbook autostart configuration if autostart # desktop file is not available system-wide for either of the shells. This # ensures that a user does not end up without any autostarted plasma shell when # a package of the active shell gets removed. if [ ! -e /usr/share/autostart/plasma-desktop.desktop ] \ [ -e /usr/share/autostart/plasma-netbook.desktop ]; then # Reset custom plasma-netbook configuration user_autostart_dir=`kde4-config --path autostart | cut -d: -f1` rm -f $user_autostart_dir/plasma-netbook.desktop elif [ -e /usr/share/autostart/plasma-desktop.desktop ] \ [ ! -e /usr/share/autostart/plasma-netbook.desktop ]; then # Reset custom plasma-desktop configuration user_autostart_dir=`kde4-config --path autostart | cut -d: -f1` rm -f $user_autostart_dir/plasma-desktop.desktop fi I haven't taken the time to understand the issue that these lines were trying to solve. But deleting the user's config is definitely not an okay way to fix it. Please could someone take a look and invent an alternative fix that doesn't clobber my settings? Thanks. Stephen ** Affects: kdebase-workspace (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1008553 Title: startkde deletes custom plasma-desktop.desktop file To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kdebase-workspace/+bug/1008553/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1008553] [NEW] startkde deletes custom plasma-desktop.desktop file
Public bug reported: I use a customised configuration for running KDE. In particular, I use fvwm as the window manager, and disable plasma-desktop by creating my own plasma-desktop.desktop file in ~/.config/autostart, which is just a copy of the one in /usr/share/autostart with Hidden=true added to it. On earlier versions of Ubuntu (up to natty, at least) this had the effect I wanted: plasma-desktop would not start up, and I could use fvwm's desktop furniture instead. I'm now re-creating this setup on a precise (12.04 LTS) install, and find that plasma-desktop not only starts when I thought I'd disabled it, but somehow, my plasma-desktop.desktop file is deleted. A bit of digging reveals the problem to be lines 381--400 of /usr/bin/startkde (from kde- workspace-bin 4:4.8.2a-0ubuntu4). # Added by Debian to fix bug #584905. # Reset user plasma-desktop/plasma-netbook autostart configuration if autostart # desktop file is not available system-wide for either of the shells. This # ensures that a user does not end up without any autostarted plasma shell when # a package of the active shell gets removed. if [ ! -e /usr/share/autostart/plasma-desktop.desktop ] \ [ -e /usr/share/autostart/plasma-netbook.desktop ]; then # Reset custom plasma-netbook configuration user_autostart_dir=`kde4-config --path autostart | cut -d: -f1` rm -f $user_autostart_dir/plasma-netbook.desktop elif [ -e /usr/share/autostart/plasma-desktop.desktop ] \ [ ! -e /usr/share/autostart/plasma-netbook.desktop ]; then # Reset custom plasma-desktop configuration user_autostart_dir=`kde4-config --path autostart | cut -d: -f1` rm -f $user_autostart_dir/plasma-desktop.desktop fi I haven't taken the time to understand the issue that these lines were trying to solve. But deleting the user's config is definitely not an okay way to fix it. Please could someone take a look and invent an alternative fix that doesn't clobber my settings? Thanks. Stephen ** Affects: kdebase-workspace (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kubuntu Bugs, which is subscribed to kdebase-workspace in Ubuntu. https://bugs.launchpad.net/bugs/1008553 Title: startkde deletes custom plasma-desktop.desktop file To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kdebase-workspace/+bug/1008553/+subscriptions -- kubuntu-bugs mailing list kubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/kubuntu-bugs
Re: [Libunwind-devel] Minimal build on NetBSD?
Has anyone tried to get libunwind building on NetBSD 5.x? I'm not a NetBSD expert, but find myself trying to get a minimal libunwind set-up running on it at fairly short order. Just clearing this up: I've now written my own simple unwinder, which handles the basic cases well enough for my purposes, so am no longer in need of help. I guess a libunwind port to NetBSD-current would be quite a bit easier now that dl_iterate_phdr is in there. There is also some relevant code in libexecinfo. I doubt I'll spend long enough on my NetBSD project to do any work on a port though, sadly. Stephen ___ Libunwind-devel mailing list Libunwind-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/libunwind-devel
[Libunwind-devel] Minimal build on NetBSD?
Has anyone tried to get libunwind building on NetBSD 5.x? I'm not a NetBSD expert, but find myself trying to get a minimal libunwind set-up running on it at fairly short order. I only need a very minimal build of libunwind, supporting just local x86 unwinding on unoptimised code. The biggest problem is that NetBSD 5.0.1 (the oldish version I'm stuck with) doesn't have dl_iterate_phdr. But I guess that we shouldn't need it just for walking an unoptimised stack that has saved break pointers. I did try the obvious hacks (remove references to libunwind-ptrace and libunwind-dwarf-* in the makefile, hack in the relevant JB_* macros since NetBSD's setjmp.h doesn't have them) and have successfully built libunwind.a and libunwind-x86.a, but currently without some important stuff (like the functions defined in src/Gos-freebsd.c). If I'm lucky, the missing stuff will port to NetBSD without huge changes, but I really don't know yet. I will hack more on this tomorrow, but if anyone has been through this already, do let me know. Thanks in advance for any help! Stephen ___ Libunwind-devel mailing list Libunwind-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/libunwind-devel
Re: [Libcdio-help] cd-info doesn't get cddb info for discs with data
Here's a *very* belated follow-up... apologies and more.
I'd say if there are *any* audio tracks, it's worth doing a CDDB
lookup. Sometimes the order is reversed, e.g. game CDs that have a
red-book audio soundtrack after the track with the game data.
Sometimes there are even multiple data tracks (e.g. one for Mac,
one for Windows).
The following trivial patch gives the CDDB behaviour I think best.
If there are any audio tracks, it should do a lookup. (The line
numbers might need a bit of fuzz, or perhaps just apply manually.)
diff --git a/src/cd-info.c b/src/cd-info.c
index f2a903e..13892d4 100644
--- a/src/cd-info.c
+++ b/src/cd-info.c
@@ -1188,8 +1188,9 @@ main(int argc, char *argv[])
report(stdout, STRONG CD Analysis Report\n NORMAL);
/* try to find out what sort of CD we have */
-if (0 == num_data) {
- /* no data track, may be a real audio CD or hidden track CD */
+if (num_audio 0) {
+ /* may be a real audio CD or hidden track CD */
msf_t msf;
cdio_get_track_msf(p_cdio, i_first_track, msf);
@@ -1209,7 +1210,8 @@ main(int argc, char *argv[])
print_analysis(ms_offset, cdio_iso_analysis, fs, first_data, num_audio,
i_tracks, i_first_track,
cdio_get_track_format(p_cdio, 1), p_cdio);
-} else {
+}
+if (num_data 0) {
/* we have data track(s) */
int j;
About the issue of test-cases for unusual CDs: I briefly started work
on a script that would rip a whole CD and then effectively delete the
content while preserving the structure. But it turns out that the first
part of this is very tricky, never mind the second. Just getting the
data out of CD-EXTRA discs is hard (extricate works). So I need to
solve the block number issues mentioned on the list last year
http://comments.gmane.org/gmane.comp.audio.libcdio.devel/547.
I might get time to work on this some time... I have no idea when. (I'm
being more cautious after saying a couple of days several months
ago. :-)
Cheers,
Stephen.
___
Libcdio-help mailing list
Libcdio-help@gnu.org
https://lists.gnu.org/mailman/listinfo/libcdio-help
[android-porting] Re: Debugging Dalvik start-up / JarVerifier problem on x86-64 Linux build
The debugger support in the VM will wait a second or two for the debugger to settle before continuing if you use android.os.Debug.waitForDebugger(). That's not enough to enter breakpoints by hand, but if you use a more sophisticated program like Eclipse it gives the debugger enough time to set breakpoints before resuming. Ah, cool -- sounds useful. That was the reminder I needed to move to the Eclipse front-end anyhow, and has helped -- thanks! That does look peculiar. I would guess the JNIEnv is bogus, and you're looking at a bunch of memory that isn't actually holding a JNI function table. Indeed, silly me -- the stack seems to be corrupt. I have now sidestepped this whole problem by commenting out the jar verification process (the initial exceptions were complaining about failing to find public keys, before being turned into other exceptions with a less helpful message -- I guess I need to install Android public keys locally for the Jars to verify? not sure why they're not in the distribution, but no matter). The fun's not over yet -- getting even stranger segfaults (without non-stop gdb) in some native calls originating in SystemServer (calling sqlite stuff). I might post back about those once I've investigated. -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting
[android-porting] Re: Debugging Dalvik start-up / JarVerifier problem on x86-64 Linux build
You may be able to just remove the assertion for your purposes.
For some reason a thread in the running state is trying to change to
running, i.e. it's a do-nothing operation that just wastes time. It
also represents a potential problem in that a bit of code that was
assuming it was in some other state has made incorrect assumptions,
which could lead to a hang or correctness problems (e.g. it thought it
was in vmwait so blocking synchronization ops are okay). The gdb
backtrace at the point of failure might be interesting, to see which
bit of code is doing the redundant update.
Cool -- thanks for this (and sorry for the delay). Here's the
backtrace:
0x00ad97fb in dvmChangeStatus (self=0xf0d057d8,
newStatus=THREAD_RUNNING)
at dalvik/vm/Thread.c:3160
3160assert(oldStatus != THREAD_RUNNING);
(gdb) bt
#0 0x00ad97fb in dvmChangeStatus (self=0xf0d057d8,
newStatus=THREAD_RUNNING)
at dalvik/vm/Thread.c:3160
#1 0x00ab0bb5 in dvmDbgThreadContinuing (status=1) at dalvik/vm/
Debugger.c:502
#2 0x00afb823 in dvmJdwpPostThreadChange (state=0x805dbe8,
threadId=value optimized out, start=true)
at dalvik/vm/jdwp/JdwpEvent.c:992
#3 0x00ab3958 in dvmDbgPostThreadStart (thread=0xf0d057d8)
at dalvik/vm/Debugger.c:2605
#4 0x00ada882 in interpThreadStart (arg=0xf0d057d8) at dalvik/vm/
Thread.c:1687
#5 0x0045f919 in start_thread () from /lib/libpthread.so.0
#6 0x0080bd4e in clone () from /lib/libc.so.6
It doesn't look too informative to me. But I can confirm that
taking out the assertion doesn't obviously break anything.
So I can now attach jdb okay, I have a different problem. To make jdb
finish attaching (and give me a prompt) I have to resume the process
in
gdb. If I resume all threads, then I don't have time to intervene
(since
jdb doesn't suspend execution when it attaches) before the failure
happens. If I try running the VM in gdb's non-stop mode, it
segfaults.
I'm going to try hacking in a pause just before the problem Java code,
so
that I can suspend from within jdb. But any clues on this segfault?
It
looks like the JNI dispatch table has been trashed---some of the
entries
are plausible, but others are clearly bogus.
(gdb) set non-stop
(gdb) break main
Breakpoint 1 at 0x804f7f2: file frameworks/base/cmds/runtime/
main_runtime.cpp, line 343.
(gdb) run
Starting program: /home/scratch/skell/android-platform-built-gcc/out/
host/linux-x86/pr/sim/system/bin/runtime
ERROR: ld.so: object '/home/scratch/skell/android-platform-built-gcc/
out/host/linux-x86/pr/sim/system/lib/libwrapsim.so' from LD_PRELOAD
cannot be preloaded: ignored.
[Thread debugging using libthread_db enabled]
Breakpoint 1, main (argc=1, argv=0xc144)
at frameworks/base/cmds/runtime/main_runtime.cpp:343
343 {
Missing separate debuginfos, use: debuginfo-install alsa-
lib-1.0.23-1.fc13.i686 glibc-2.12.2-1.i686 libgcc-4.4.4-10.fc13.i686
libstdc++-4.4.4-10.fc13.i686
(gdb) break AndroidRuntime.cpp:974
Breakpoint 2 at 0x1f73be: file frameworks/base/core/jni/
AndroidRuntime.cpp, line 974.
(gdb) cont
Continuing.
I/runtime (30688): commandline args:
I/runtime (30688):0: '/home/scratch/skell/android-platform-built-
gcc/out/host/linux-x86/pr/sim/system/bin/runtime'
I/runtime (30688): Startup: sys='/home/scratch/skell/android-platform-
built-gcc/out/host/linux-x86/pr/sim/system' asset='/home/scratch/skell/
android-platform-built-gcc/out/host/linux-x86/pr/sim/system/app'
data='/home/scratch/skell/android-platform-built-gcc/out/host/linux-
x86/pr/sim/data'
W/ProcessState(30688): Opening '/dev/binder' failed: No such file or
directory
I/runtime (30688): Entered boot_init()!
I/runtime (30688): Binder driver not found. Processes not supported.
I/AndroidRuntime(30688): Using TCP socket for JDWP
I/AndroidRuntime(30688): Assertions enabled: '-ea'
[New Thread 0x1edeb70 (LWP 30923)]
[New Thread 0x28dfb70 (LWP 30924)]
[New Thread 0x32e0b70 (LWP 30925)]
[New Thread 0x3ce1b70 (LWP 30926)]
Breakpoint 2, android::AndroidRuntime::start (this=0x8055fa8,
className=0x80507b0 com/android/server/SystemServer,
startSystemServer=false) at frameworks/base/core/jni/
AndroidRuntime.cpp:974
974 env-CallStaticVoidMethod(startClass, startMeth,
strArray);
(gdb) step
_JNIEnv::CallStaticVoidMethod (this=0xf6fe1090, clazz=0xf6acce14,
methodID=0xf6fe0f58)
at dalvik/libnativehelper/include/nativehelper/jni.h:789
789 void CallStaticVoidMethod(jclass clazz, jmethodID
methodID, ...)
(gdb) step
792 va_start(args, methodID);
(gdb) step
793 functions-CallStaticVoidMethodV(this, clazz,
methodID, args);
(gdb) step
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x001f790a in _JNIEnv::CallStaticVoidMethod (this=0xf6fe1090,
clazz=0xf6acce14, methodID=0xf6fe0f58)
at dalvik/libnativehelper/include/nativehelper/jni.h:793
#2 0x080548c8 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
[android-porting] Debugging Dalvik start-up / JarVerifier problem on x86-64 Linux build
Hi, Can someone give me tips about how to debug Dalvik start-up? I'm trying to attach jdb to the VM as early as I can, to debug some JarVerifier problems on start-up of the Android runtime. But this causes Heisenbergian assertion failures (i.e. that I don't see when not debugging). This is a build of Android for my desktop x86-64 machine running FC13. (Quick summary: I'm resurrecting the sim build, for my own sinister purposes that you can ask me about if you like.) If I attach jdb before the InvokeStaticMethod that calls main, it causes an assertion failure. Alternatively, if you can tell why the verification is failing, I can maybe live without being able to attach the debugger early! This is the error I'm trying to debug. W/PackageParser(26345): Exception reading AndroidManifest.xml in /home/ scratch/skell/android-platform-built-gcc/out/host/linux-x86/pr/sim/ system/framework/framework-res.apk: java.lang.SecurityException: /home/ scratch/skell/android-platform-built-gcc/out/host/linux-x86/pr/sim/ system/framework/framework-res.apk failed verification of META-INF/ CERT.SF W/PackageParser(26345): java.lang.SecurityException: /home/scratch/ skell/android-platform-built-gcc/out/host/linux-x86/pr/sim/system/ framework/framework-res.apk failed verification of META-INF/CERT.SF W/PackageParser(26345): at java.util.jar.JarVerifier.failedVerification(JarVerifier.java:135) W/PackageParser(26345): at java.util.jar.JarVerifier.verifyCertificate(JarVerifier.java:312) W/PackageParser(26345): at java.util.jar.JarVerifier.readCertificates(JarVerifier.java:265) W/PackageParser(26345): at java.util.jar.JarFile.getInputStream(JarFile.java:389) W/PackageParser(26345): at android.content.pm.PackageParser.loadCertificates(PackageParser.java: 343) W/PackageParser(26345): at android.content.pm.PackageParser.collectCertificates(PackageParser.java: 491) W/PackageParser(26345): at com.android.server.PackageManagerService.collectCertificatesLI(PackageManagerService.java: 2570) W/PackageParser(26345): at com.android.server.PackageManagerService.scanPackageLI(PackageManagerService.java: 2656) W/PackageParser(26345): at com.android.server.PackageManagerService.scanDirLI(PackageManagerService.java: 2514) W/PackageParser(26345): at com.android.server.PackageManagerService.init(PackageManagerService.java: 930) W/PackageParser(26345): at com.android.server.PackageManagerService.main(PackageManagerService.java: 694) W/PackageParser(26345): at com.android.server.ServerThread.run(SystemServer.java:149) E/PackageParser(26345): Package android has no certificates at entry AndroidManifest.xml; ignoring! W/PackageManager(26345): Failed verifying certificates for package:android If I break the dalvikvm in gdb before it does Check_CallStaticVoidMethodV, then attach jdb and resume both, I get the following. E/dalvikvm(26824): ASSERT FAILED (dalvik/vm/Thread.c:3160): oldStatus ! = THREAD_RUNNING Program received signal SIGSEGV, Segmentation fault. 0x00ad97fb in dvmChangeStatus (self=0x8056820, newStatus=THREAD_RUNNING) at dalvik/vm/Thread.c:3160 3160assert(oldStatus != THREAD_RUNNING); ... whereas if I step through the main call from gdb, the assertion checks okay. I've tried a few variations on that theme too, attaching the debugger at various points. But they always trigger the assertion failure. It seems like attaching jdb does something to thread statuses that dvmChangeStatus assumes will never happen. This is all on dalvikvm build from the current-ish Android tree (checked out in May) . Thanks for any suggestions! Let me know what extra information I can provide Stephen -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting
[Libcdio-help] cd-info doesn't get cddb info for discs with data
Hi, I'm fairly sure I've run into a bug in cd-info. For audio discs with a trailing data track -- like a lot of CD singles and various others -- print_analysis() is skipped and no CDDB info is printed. The offending code is around lines 1190--1245 of cd-info.c. I don't have time to cook up a patch right now, but I can do in a little while if need be. I've pasted the output for my CD of Bowie's Station to Station, which has a data track at the end. Let me know if I can provide any other information. Thanks (for any help, and for working on libcdio!), Stephen. stephen@ernest-4:/usr/local/src/libcdio-0.81$ cd-info cd-info version 0.81 x86_64-pc-linux-gnu Copyright (c) 2003, 2004, 2005, 2007, 2008 R. Bernstein This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. CD location : /dev/cdrom CD driver name: GNU/Linux access mode: ioctl Vendor : OEM Model : CD-ROM F564E Revision: 1.15 Hardware : CD-ROM or DVD Can eject : Yes Can close tray: Yes Can disable manual eject : Yes Can select juke-box disc : No Can set drive speed : No Can read multiple sessions (e.g. PhotoCD) : Yes Can hard reset device : No Reading Can read Mode 2 Form 1 : Yes Can read Mode 2 Form 2 : Yes Can read (S)VCD (i.e. Mode 2 Form 1/2) : Yes Can read C2 Errors : Yes Can read IRSC : Yes Can read Media Channel Number (or UPC) : Yes Can play audio : Yes Can read CD-DA : Yes Can read CD-R : Yes Can read CD-RW : Yes Can read DVD-ROM: No Writing Can write CD-RW : No Can write DVD-R : No Can write DVD-RAM : No Can write DVD-RW: No Can write DVD+RW: No __ Disc mode is listed as: CD-DA CD-ROM Track List (1 - 7) #: MSF LSNType Green? Copy? Channels Premphasis? 1: 00:02:00 00 audio false no2no 2: 10:16:27 046077 audio false no2no 3: 14:16:72 064122 audio false no2no 4: 20:20:62 091412 audio false no2no 5: 25:54:60 116460 audio false no2no 6: 32:10:22 144622 audio false no2no 7: 40:42:42 183042 data false no 170: 43:20:16 194866 leadout (437 MB raw, 437 MB formatted) Media Catalog Number (MCN): 0724352190607 Last CD Session LSN: 183042 audio status: no status volume level port 0: 255 (0..255) 100 (0..100) volume level port 1: 255 (0..255) 100 (0..100) volume level port 2: 0 (0..255) 0 (0..100) volume level port 3: 0 (0..255) 0 (0..100) __ CD Analysis Report session #2 starts at track 7, LSN: 183042, ISO 9660 blocks: 194714 ISO 9660: 194714 blocks, label `BOWIE ' ___ Libcdio-help mailing list Libcdio-help@gnu.org https://lists.gnu.org/mailman/listinfo/libcdio-help
[bug #17043] CD boot fails loading stage 2, for some filesystem structures only
Follow-up Comment #1, bug #17043 (project grub): I've identified the the cause of this problem. It seems that if I add -boot-info-table to my mkisofs command, the problem goes away. Reading the mkisofs man page, nowhere does it say that this option is mandatory, and I can't find a mention of it in the El Torito v1.0 spec. Perhaps the grub documentation should be modified to mention that the info table is required by grub? Thanks to adrian15 for some suggestions. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=17043 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-grub mailing list Bug-grub@gnu.org http://lists.gnu.org/mailman/listinfo/bug-grub
[bug #17043] CD boot fails loading stage 2, for some filesystem structures only
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=17043 Summary: CD boot fails loading stage 2, for some filesystem structures only Project: GNU GRUB Submitted by: srk31 Submitted on: Thursday 07/06/2006 at 11:48 Category: Booting Severity: Major Priority: 5 - Normal Item Group: Software Error Status: None Privacy: Public Assigned to: None Originator Name: Stephen Kell Originator Email: [EMAIL PROTECTED] Open/Closed: Open Release: 0.97 Reproducibility: Every Time Planned Release: ___ Details: I've successfully made a working bootable CD using GRUB 0.97. However, if I re-make the CD with a slightly altered directory structure (by adding one or more directories) I get a variety of similar errors on boot. If I add only one directory, I see: Loading stage2 Loading stage2 Loading stage2 Loading stage2 (many times, terminated by either Loading stage2 ..FATAL: bios_printf: unknown format or a complete lock-up, seemingly at random) If I add several directories, I see: Loading stage2 Read error 0x80 The filesystem that works looks like this: . |-- REVISION |-- boot | |-- System.map-2.6.16-1-486 | |-- System.map-2.6.16.13-xen | |-- config-2.6.16-1-486 | |-- config-2.6.16.13-xen | |-- grub | | |-- default | | |-- device.map | | |-- e2fs_stage1_5 | | |-- fat_stage1_5 | | |-- ffs_stage1_5 | | |-- jfs_stage1_5 | | |-- menu.lst | | |-- minix_stage1_5 | | |-- nbgrub | | |-- pxegrub | | |-- reiserfs_stage1_5 | | |-- stage1 | | |-- stage2 | | |-- stage2.netboot | | |-- stage2_eltorito | | |-- vstafs_stage1_5 | | `-- xfs_stage1_5 | |-- initrd-2.6.16-1-486.img | |-- initrd-2.6.16.13-xen.img | |-- vmlinux-syms-2.6.16.13-xen | |-- vmlinuz-2.6-xen - vmlinuz-2.6.16.13-xen | |-- vmlinuz-2.6.16-1-486 | |-- vmlinuz-2.6.16-xen - vmlinuz-2.6.16.13-xen | |-- vmlinuz-2.6.16.13-xen | |-- xen-3.0.2-3.gz | |-- xen-3.0.gz - xen-3.0.2-3.gz | |-- xen-3.gz - xen-3.0.2-3.gz | |-- xen-syms-3.0.2-3 | `-- xen.gz - xen-3.0.2-3.gz |-- boot.catalog |-- rootfs.img `-- xen-3.0-testing-20060627.tar.bz2 2 directories, 37 files One that displays the first described errors looks like this: . |-- REVISION |-- boot | |-- System.map-2.6.16-1-486 | |-- System.map-2.6.16.13-xen | |-- config-2.6.16-1-486 | |-- config-2.6.16.13-xen | |-- grub | | |-- default | | |-- device.map | | |-- e2fs_stage1_5 | | |-- fat_stage1_5 | | |-- ffs_stage1_5 | | |-- jfs_stage1_5 | | |-- menu.lst | | |-- minix_stage1_5 | | |-- nbgrub | | |-- pxegrub | | |-- reiserfs_stage1_5 | | |-- stage1 | | |-- stage2 | | |-- stage2.netboot | | |-- stage2_eltorito | | |-- vstafs_stage1_5 | | `-- xfs_stage1_5 | |-- initrd-2.6.16-1-486.img | |-- initrd-2.6.16.13-xen.img | |-- vmlinux-syms-2.6.16.13-xen | |-- vmlinuz-2.6-xen - vmlinuz-2.6.16.13-xen | |-- vmlinuz-2.6.16-1-486 | |-- vmlinuz-2.6.16-xen - vmlinuz-2.6.16.13-xen | |-- vmlinuz-2.6.16.13-xen | |-- xen-3.0.2-3.gz | |-- xen-3.0.gz - xen-3.0.2-3.gz | |-- xen-3.gz - xen-3.0.2-3.gz | |-- xen-syms-3.0.2-3 | `-- xen.gz - xen-3.0.2-3.gz |-- boot.catalog |-- rootfs.img |-- scripts | |-- README | |-- e2fs-zero.py | |-- make-livecd | |-- update-initrd | `-- update-rootfs `-- xen-3.0-testing-20060627.tar.bz2 3 directories, 42 files i.e. it has the scripts directory added. I've tried many variations, and it doesn't seem to matter whether the directory contains any files, or what it's called, or even whether it's added in the root or in /boot. If I add several directories (three or more), I see the second of the error cases described above. The CDs are all built using the following command: mkisofs -r -J -z -no-emul-boot -b boot/grub/stage2_eltorito -c boot.catalog -boot-load-size 4 -o /dev/stdout /store/tmp/working/new-iso-fs some-file.iso where /store/tmp/working/new-iso-fs is a directory as shown above. Note that I'm using transparent compression, but not on any files in /boot/grub. I also tried without the compression, with no change. I've also tried removing all files from boot/grub except stage2_eltorito and menu.lst, but that has no effect. The menu.lst looks as follows: terminal console timeout 10 default 0 title Debian-based Dom0 (from testing) root (cd) kernel /boot/xen-3.0.2-3.gz watchdog module /boot/vmlinuz-2.6.16.13-xen ro selinux=0 ramdisk_size=32758 image=rootfs.img boot=cow module /boot/initrd-2.6.16.13-xen.img title Debian-based Dom0 in text mode (from testing) root (cd) kernel /boot/xen-3.0.2-3.gz watchdog module /boot/vmlinuz-2.6.16.13-xen ro 2 selinux=0
Bug#342341: eclipse: too many unneeded dependencies
Is there any reason why Jan's suggested changes haven't been made? I too would be very happy to see them applied. Stephen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
