Re: Publishing developer documentation (was Re: The role of the docmaster)
Hi, Quim Gil wrote: First of all, let's remember the defined goals: http://wiki.maemo.org/Objective:Co-production_of_official_%26_community_documentation One of the issues I've had is separating goals and means to attaining those goals. Co-production of documentation of documentation is clearly an end-goal. Making it easy(ier) for community members to help contribute documentation, and fix documentation issues, is also an end goal. Having documentation handled by the wiki is not an end goal, however, it is one possible means to the end goal of making contribution easier. - API references. Generated from source code. Their publishing and contribution processes are as open and collaborative as their related source code. No less, no more. Always on-line on HTML pages updated directly from the code. The tools are specific, bug reports and code repositories to commit contributions. Owned by Maemo Devices and published in maemo.org. We have already contacted Fred Peters, creator of http://library.gnome.org/ , to have a good solution in place by the Maemo 5 final release. The quality is defined by valid references (mapped to current code) and working code. The descriptions of the APIs need to be clear and undestandable by developers. Agreed - once the repository of a module is public, contributing documentation fixes here is as straightforward as submitting a patch. - Technical documentation. The Maemo Reference Guide, derived directly from the API references: what Maemo allows application and also platform developers to do. Human readable but without much flourishing. Always on-line with only a marginal case for printed versions. Wiki is an ideal support for fast an easy contributions. Everybody can add feedback in the Talk pages an contributors with special permissions can edit the main content. Then something like http://www.mediawiki.org/wiki/Extension:Pdf_Book could be used to allow Nokia and whoever else to create PDF files directly out of the wiki content, that would be the one and only source. This needs more discussion and an agreement on how to proceed. Target: Harmattan since we have a process in place already for Fremantle. Owned by Maemo Devices. The quality criteria are the same as in API references + even more accuracy in language and good provision of examples in the form of graphics, code snippets and demo apps. Here's the tricky bit - the current constraints for technical documentation that I have been given are: * It must be possible to have both private and public updates of documentation (due to product embargoes, and documentation documenting not-yet-announced features) * High quality printed documentation must be possible * Lower the barrier to community contribution * Documentation contributions from the community must undergo review before being integrated into official documentation I have suggested making a public SCM for all public releases of documentation in their source format, to allow patches to be submitted. This should happen after the next release. My major concern with plans I have seen for the moment is that there will be major issues bringing changes made to the wiki back to the official documentation, and vice versa. We're in a classic situation where you have to merge two branches, but without the proper tools to do so. Last year when we discussed this in Bugzilla, you said that the plan was to have official docs published read-only in the wiki, with people making suggestions on the Talk pages, and these suggestions would be integrated back into the official documentation. Is that still the plan? - Generic developer documentation. Tutorials, training materials and other educational/introductory/marketing documentation. Derived mainly from the technical documentation and ready to be published in many formats, including videos, books, PDFs... Online editable formats e.g. wiki pages can be possible too, but the default scenario are stable and consolidated documents published once and updated only when really needed. Improvements to be proposed via bug reports unless the specific document has a more direct way to apply changes. The quality criteria are the same as in the technical documentation with a special emphasis in the language, the structure of the content, the visual appearance and the cleverness of the content and the examples provided. Forum Nokia is responsible of this kind of documentation, and they are getting ready for this in Fremantle and even more in Harmattan onwards. In general, I would like to see the sources (whether they be docbook or latex) available in a public SCM for all published documentation. This would allow people to generate their owm PDFs, web versions, integrate with Yelp or DevHelp, etc. It will also allow people to submit patches using standard tools and reduce the maintenance burden of developers. Is this something you see happening for these types of documentation? As I see
PC Connectivity for Jaunty?
Hi, I was trying to install Maemo PC Connectivity on Jaunty, using these instructions: http://pc-connectivity.garage.maemo.org/installation.html they say to add this line to sources.list: deb http://pc-connectivity.garage.maemo.org/repository intrepid main I substituted intrepid with jaunty, but when I run apt-get update I get errors: W: Failed to fetch http://pc-connectivity.garage.maemo.org/repository/dists/jaunty/main/binary-i386/Packages 404 Not Found E: Some index files failed to download, they have been ignored, or old ones used instead. isn't it available for Jaunty? Thanks for your support! -- Andrea Grandi email: a.grandi [AT] gmail [DOT] com website: http://www.andreagrandi.it PGP Key: http://www.andreagrandi.it/pgp_key.asc ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N800 Power cycles
Hi, ext Rainer Dorsch wrote: I modified that too if [ x$bootreason = xcharger ]; then echo Showing the 'charger connected' image /usr/bin/fb-chaimage -l /usr/share/images/qgn_indi_charger_connection_detected -b 0 -c -p 0 -s 15 else text2screen -t Bootreason: `cat /proc/bootreason` -H center -y 360 -s 6 -B 0x fi This way I have at least some information when I run in that problem next time. Is there any other debug information which would be useful to print? maybe statistics from /var/lib/dsme/stats/ files? Is there a way (by changing linuxrc further) to get a lot more information during boot instead of the nice but almost informationfree image? Using the text2screen utility above? I just noticed that I cannot write that file, the fs is mounted readonly: /dev/root on /mnt/initfs type jffs2 (ro) If I remount it rw mount -o remount,rw /mnt/initfs to do the change, would that break something? Initfs may be too full for changes. You need to remove things first (e.g. initfs factory test stuff you can find -name '*test*'). - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N800 Power cycles
Eero Tamminen wrote: Hi, Is there a way (by changing linuxrc further) to get a lot more information during boot instead of the nice but almost informationfree image? Using the text2screen utility above? Some additional tips are here http://talk.maemo.org/showthread.php?t=16056 With easy modification you may see which /etc/init.d/* scripts are started and syslog may help a lot too. I just noticed that I cannot write that file, the fs is mounted readonly: /dev/root on /mnt/initfs type jffs2 (ro) If I remount it rw mount -o remount,rw /mnt/initfs to do the change, would that break something? No but it allows you (or some code running as root) to mess it up. initfs was more or less writable (i.e. mounted 'rw' but more or less full) since OS2005 days, changing mount options to 'ro' is new in Diablo. Also mounting it 'rw' eats some tiny bits of memory by having extra jffs_gcd_mtd3 garbage collection kernel thread running. Initfs may be too full for changes. You need to remove things first (e.g. initfs factory test stuff you can find -name '*test*'). It was full before Diablo. In Diablo initfs partition was enlarged so there is enough free space at least for N800 and plain N810. The wimax edition has some additional firmware and binaries so the free space may be bad again. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
asking help about installing xephyr
Hi maemo and linux experts, I am quite new to linux and maemo. I can\t install xephyr of maemo 4.1.2 diablo in my ubuntu 8.04 (Wubi within vista), and some errs happened as following. I have been struggling for it long time. please give your hands kindly. s...@liuyp-laptop:~$ DISPLAY=:0 Xephyr -screen 480x640 -dpi 283 -ac -br :1 [1] 8356 s...@liuyp-laptop:~$ expected keysym, got XF86KbdLightOnOff: line 70 of pc expected keysym, got XF86KbdBrightnessDown: line 71 of pc expected keysym, got XF86KbdBrightnessUp: line 72 of pc expected keysym, got XF86KbdLightOnOff: line 70 of pc expected keysym, got XF86KbdBrightnessDown: line 71 of pc expected keysym, got XF86KbdBrightnessUp: line 72 of pc Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! s...@liuyp-laptop:~$ DISPLAY=:2 Xephyr -screen 480x640 -dpi 283 -ac -br :1 Fatal server error: Server is already active for display 1 If this server is no longer running, remove /tmp/.X1-lock and start again. [2] 8362 [2]+ Exit 1 DISPLAY=:2 Xephyr -screen 480x640 -dpi 283 -ac -br :1 s...@liuyp-laptop:~$ DISPLAY=:0 Xephyr -screen 480x640 -dpi 283 -ac -br :1 XIO: fatal IO error 11 (Resource temporarily unavailable) on X server :0.0 after 579 requests (579 known processed) with 0 events remaining. [2] 8416 [1] Exit 1 DISPLAY=:0 Xephyr -screen 480x640 -dpi 283 -ac -br :1 s...@liuyp-laptop:~$ expected keysym, got XF86KbdLightOnOff: line 70 of pc expected keysym, got XF86KbdBrightnessDown: line 71 of pc expected keysym, got XF86KbdBrightnessUp: line 72 of pc expected keysym, got XF86KbdLightOnOff: line 70 of pc expected keysym, got XF86KbdBrightnessDown: line 71 of pc expected keysym, got XF86KbdBrightnessUp: line 72 of pc Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! s...@liuyp-laptop:~$ XIO: fatal IO error 11 (Resource temporarily unavailable) on X server :0.0 after 324 requests (324 known processed) with 0 events remaining. [2]+ Exit 1 DISPLAY=:0 Xephyr -screen 480x640 -dpi 283 -ac -br :1 s...@liuyp-laptop:~$ Xephyr :2 -host-cursor -screen 800x480x16 -dpi 96 -ac -extension Composite Xephyr cannot open host display. Is DISPLAY set? s...@liuyp-laptop:~$ scratchbox Welcome to Scratchbox, the cross-compilation toolkit! Use 'sb-menu' to change your compilation target. See /scratchbox/doc/ for documentation. [sbox-DIABLO_X86: ~] export DISPLAY=:2 [sbox-DIABLO_X86: ~] af-sb-init.sh start Note: For remote X connections DISPLAY should contain hostname! Sample files present. Starting DBUS system bus Starting D-BUS session bus daemon Starting Maemo Launcher: maemo-launcher. maemo-launcher: warning rising the oom shield for pid=8526 status=5632 Starting Sapwood image server Starting Matchbox window manager Starting clipboard-manager Starting Keyboard maemo-launcher: invoking '/usr/bin/hildon-input-method.launch' Starting Hildon Desktop maemo-launcher: invoking '/usr/bin/hildon-desktop.launch' [sbox-DIABLO_X86: ~] _X11TransSocketINETConnect() can't get address for localhost:6002: Temporary failure in name resolution sapwood-server[8537]: GLIB WARNING ** Gdk - cannot open display: _X11TransSocketINETConnect() can't get address for localhost:6002: Temporary failure in name resolution matchbox-wm: can't open display! check your DISPLAY variable. _X11TransSocketINETConnect() can't get address for localhost:6002: Temporary failure in name resolution Could not open display. Is the DISPLAY environment variable set? _X11TransSocketINETConnect() can't get address for localhost:6002: Temporary failure in name resolution hildon-input-method[8569]: GLIB WARNING ** Gtk - cannot open display: maemo-launcher: child (pid=8569) terminated due to exit()=1 _X11TransSocketINETConnect() can't get address for localhost:6002: Temporary failure in name resolution hildon-desktop[8584]: GLIB WARNING ** Gtk - cannot open display: maemo-launcher: child (pid=8584) terminated due to exit()=1 [sbox-DIABLO_X86: ~] logout s...@liuyp-laptop:~$ Xephyr :2 -host-cursor -screen 800x480x16 -fp /usr/share/fonts/X11/cyrillic -dpi 96 -ac -extension Composite Xephyr cannot open host display. Is DISPLAY set? s...@liuyp-laptop:~$ scratchbox Welcome to Scratchbox, the cross-compilation toolkit! Use 'sb-menu' to change your compilation target. See /scratchbox/doc/ for documentation. [sbox-DIABLO_X86: ~] export DISPLAY=:2 [sbox-DIABLO_X86: ~] af-sb-init.sh start Note: For remote X connections DISPLAY should contain hostname! Sample files present. DBUS system bus is already running, doing nothing D-BUS session bus daemon is already running, doing nothing Starting Maemo Launcher: maemo-launcher start failed. Starting Sapwood image server Starting Matchbox window manager Starting clipboard-manager Starting Keyboard maemo-launcher: invoking '/usr/bin/hildon-input-method.launch' Starting Hildon Desktop maemo-launcher: invoking '/usr/bin/hildon-desktop.launch'
Default nice value setting
Hi, Is there a way to specify a default nice value for an application on maemo? I noticed that if an application is launched by the menu directly from an executable (using the Exec variable in the .desktop file) it gets a nice value of -1. But, if the application is started over D-Bus (using the X-Osso-Service variable in the .desktop file) it gets a nice value of 0. The application I'm working on needs at least a nice value of -1 or else it becomes unusable. Is there a way to make this happen while still being able to start the application over D-Bus? Thanks, nick ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
