Re: Maemo Reconstructed (Busybox)
Hi, ext Carsten Valdemar Munk wrote: For the last week I've been working on a proposal for a possible future system architecture of Maemo, covering areas such as boot process, base system, user experience base and SDK. This was sparked by the discussions in https://wiki.maemo.org/Mainstream_Linux_Alignment , http://qgil.jaiku.com/presence/47635104 and my last post to this list, http://lists.maemo.org/pipermail/maemo-developers/2008-October/035409.html You can view, edit and contribute (or object to parts) to to the proposal on http://wiki.maemo.org/Maemo_Reconstructed From the page: -- Discussion: Is busybox really needed on a tablet? In initfs, sure, but in the actual system? Having sane coreutils and bsdutils (and debconf) -really- helps porting. Now that dash exists, is there a reason for busybox as sh? This avoids any conflicts with coreutils, bsdutils etc if they are going to be used. * A simple (which may be unfair and inaccurate) experiment with dpkg-deb -x of procps, coreutils, util-linux, bsdutils into a path, and then mkjffs'ing it after stripping man pages, locales and info pages, - 2.2mb flash, and - with busybox getting same treatment, 300k flash. -- If you check what Busybox provides on the device: $ dpkg -s busybox|grep Provides|tr ',' '\n' You should compare Busybox footprint against following Debian packages: - findutils - gzip - hostname - ifupdown - module-init-tools - net-tools - procps - sed - tar - coreutils - grep - mount - login - debianutils - util-linux - vim-tiny - mawk - mktemp - bsdutils - sysvinit-utils - iputils-ping - psmisc - time -- Scratchbox (cross-compilation environment) Build programs for another architecture/target than on the one compiling. Packages for Maemo should not expect Scratchbox to be where they're compiled (There's been seen examples of this amongst Nokia code.). This increases portability of Maemo platform. A package that builds in Scratchbox should also build on a tablet. -- Debian packages in general aren't buildable with Busybox, so above would be pending on this: https://bugs.maemo.org/show_bug.cgi?id=2896 And on modified build-essentials metapackage that brings in the suitable GNU tools I guess. /Carsten V. Munk Developer on the Deblet Project, Diablo user and happy tablet user. - Eero PS. Is The Deblet Project a registered legal entity and do you require copyright assignments? If not, it may be better if developers use just their own copyright with a commonly agreed license instead of The Deblet Project copyright as suggested in the Deblet www-page. The code could still say part of the Deblet project or something similar. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo Reconstructed (Busybox)
First off, I'd like to thank you for your constructive input, and I've added your findings to the Talk page for later inclusion into the proposal. Quoting Eero Tamminen [EMAIL PROTECTED]: A package that builds in Scratchbox should also build on a tablet. -- Debian packages in general aren't buildable with Busybox, so above would be pending on this: https://bugs.maemo.org/show_bug.cgi?id=2896 And on modified build-essentials metapackage that brings in the suitable GNU tools I guess. Yes, - that would be a requirement, one which would also be a part of the reconstructed Maemo, a system where it is possible to drag in a build-essentials package just as easy as it is with a Debian installation, for instance. /Carsten V. Munk Developer on the Deblet Project, Diablo user and happy tablet user. PS. Is The Deblet Project a registered legal entity and do you require copyright assignments? No legal entity as such (I guess, beyond the manifestation of developers of the project) and we don't require copyright assignments as it's mostly a tablet enthusiast project. If not, it may be better if developers use just their own copyright with a commonly agreed license instead of The Deblet Project copyright as suggested in the Deblet www-page. The code could still say part of the Deblet project or something similar. Well, we don't demand contributors assign the copyright or use this specific license. The one on the page is mostly meant as a indication of copy of the material on the wiki and such, and if there was any doubt when packages are missing licenses. For me, it just means that people are actually licensed to use the material code, - I'm happy as long as I'm credited, so. /Carsten Munk ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Disable auto uppercase on input?
On Tue, Nov 04, 2008 at 08:26:42PM +0100, Till Harbaum / Lists wrote: i know that this auto uppercase for the first letter can be disabled in the control panel. But how do i disable this from my program? http://maemo.org/api_refs/4.0/gtk/GtkEntry.html#hildon-gtk-entry-set-input-mode http://maemo.org/api_refs/4.0/gtk/GtkIMContext.html#HildonGtkInputMode GtkWidget *entry = gtk_entry_new (); hildon_gtk_entry_set_input_mode (GTK_ENTRY (entry), HILDON_GTK_INPUT_MODE_FULL); -- Alberto García González http://people.igalia.com/berto/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Busybox version
Hi, ext Eero Tamminen wrote: ext Marius Vollmer wrote: The whole point of my alternatives proposal is that it doesn't need to remove the lock. No Nokia components are ever removed, and Nokia OS upgrades continue to upgrade the Nokia-provided alternatives as usual, but the user can choose (through the alternatives mechanism) to not use those but to use others instead. This would be specific to busybox and would need cooperation from Nokia. I think it would be better to find an arrangement that works in general and that doesn't require waiting for Nokia to do something. If my alternatives proposal is too complex, I do have another option: the ported packages are changed to install the utilities into /usr/local/ and users (or packages) which want to use them learn to put /usr/local/bin in their path before the standard locations. What about dpkg-divert, or just using Replace (without Conflict) to overwrite the busybox symlinks from your package. dpkg-divert requires modifying each package replacing anything from Busybox, updates-alternatives requires modifying both busybox and each package replacing anything from Busybox. The symbol links proposal requires changing just busybox package but doesn't work as well for OS upgrades. I've finally had time to finish/try first proto of this splitup thing. However, the OS/Busybox upgrade may be a bit more complicated than I though. The problem is that because Busybox package won't anymore provide any symlinks by itself, and all symlink packages depend from exact Busybox version[1], all the symlinks disappear when a new version of the busybox package is installed. However, rm and tar are needed to be able to continue installing the updated symlink packages. [1] To make sure that Busybox really includes all tools which are symlinked to it. There are couple of solutions for this: 1) OS upgrade adds temporary rm tar symlinks to Busybox until busybox symlinks packages are updated. Downside is that then upgrading just Busybox wouldn't work unless one creates these symlinks manually beforehand, so I don't think this is good enough. 2) The exact version dependency to busybox is removed from the symlink packages. This allows keeping the old symlinks when Busybox is upgraded. The downside is that then there's nothing guaranteeing that the Busybox configuration matches what the symlink packages expect. I think 2) would be acceptable if only Busybox symlink packages marked as essential have this generic dependency. For those we should anyway have much stricter control of what busybox provides for them. Busybox source package modified to support the symlink packages could e.g. reject configurations that don't include certain required binaries. (If somebody would want to upgrade Diablo Busybox to this kind of new version of Busybox package, a kludge like 1) would still be needed and new Busybox would need to be installed before the symlinks packages.) Comments? However, I don't think that is a problem because busybox symlink packages split up doesn't prevent from using dpkg-diverts in the replacements or putting them to /usr/local. So, I think the split up is the best solution to start with. Somebody could also add later the alternatives support to busybox in addition to the symlinks package split up. Though first I would like to see a list of which busybox utilities need this with some explanations why (it isn't e.g. something that should be fixed in Busybox itself). Maybe there could be a wiki page listing Busybox shortcomings? - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
ALSA PCM DSP Plugin
Can anyone tell me if the dsp tasks for pcm output allows non-blocking calls and if it supports async operation via callback/semaphore? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: ALSA PCM DSP Plugin
Can anyone tell me if the dsp tasks for pcm output allows non-blocking calls and if it supports async operation via callback/semaphore? You should be able to tell by looking at the ARM-side (and available) source for the Gstreamer DSP plugins. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to get a general utility package cross-listed from tools to extras?
This is no longer academic as my minigpsd program is sitting in extras-devel, and the ONLY problem it has is the bluez-utils-test dependency. (I did add a few things to the extras howto wiki to map some obstacles, e.g. user/navigation, not user/Navigation, and the Build-Dependencies explaining the reason). Now, how do I get bluez-utils-test moved somewhere it can be found as an ordinary dependency. If the whole point of this process is to have things cleanly in Extras and not private repositories, and not require hacking or installing sdk/tools, or red-pill, there needs to be a way of maybe promoting/cross-listing an SDK or tools package to Extras or some other official place and category (maybe automatically if it is a dependency - the autobuilder seems to do a lot of really good stuff already) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Source code of osso-iradio-applet
Hi maemo developers! I am looking for the sources of the osso-iradio-applet, I did not find them in the svn repository. So I think the sources are not released under an open source license. I am asking the responsible people at Nokia now, is it possible to release the sources of osso-iradio-applet under an open source license? I would like to integrate radio clock features into the applet. I have currently implemented a prototype of a standalone alarm applet, but I think it makes much more sense to integrate the alarm feature into the existing internet radio applet. Cheers, Hermann ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Problems accessing the camera in Flash
I was playing around with a Flash program that runs in a browser and sends the video stream from your computer/web camera out to another party. I've tried it on a Nokia n810 and I can see the camera output from a desktop computer coming in, but the other side cannot see the output of my Nokia n810 camera. I figure it has something to do with the Flash program not recognizing that a camera exists or that the camera is not registered in the right way on the device so that the Flash program can see it and connect to it. Does any one have any idea about this of how to fix it or have any theories about what might be going on? Thanks. Merrick F. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Announcing PenguinTV, rss reader and podcast downloader
It depends on python2.5-dbus, python2.5-conic They are not pulled in by default. The package installs, but dies silently (unless run from a console). There may be more dependencies but I've already installed a lot of python modules. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
