How to change system volume in C language?
Hi, I have searched a lot, but still can not find out the way to change system volume ?Could you give me an example?Thanks very much! 2008-08-21 dumganhar ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Location of /home, /tmp and /var folder kills tablet device in a couple of months
Oliver wrote: > Frantisek wrote > > >> See some explanation in >> http://bugs.maemo.org/show_bug.cgi?id=598#c9 >> >> If you are concerned about this you can also boot whole system from >> SD/MMC card - http://wiki.maemo.org/Booting_from_a_flash_card >> >> > > Thank's for your answer. > This clarifies a lot. > > Being able to use the device for about over 30 years is sufficient for me. > But still i would like to know if it is save to move those directories to my > external SD flash drive. I won't remove > the SD drive on a daily basis, but i want to know when the system is mounting > the SD flash drive > because want be sure, that the device mounts the SD flash drive before > accessing the files on these directories. > So when does the system mount the device or when does it have access to it? > > This interests me also, because i want to move the /usr directory to the 2 GB > internal flash drive because i need more space than 256 MB for user space > programms. > For example i want install a compiler + dev and documentation files on the > device, that's why i will need the 2 GB for > the software. > > So it is save to move those directories and changing the /etc/fstab entry or > could this result in a problem booting the device? > If the latter is the case, is there a way to rescue the system? > I think you're much better off by leaving the internal flash alone and just booting straight from SD card. That would give you the space that you need while allowing the device to boot without the card if needed. This also simplfies upgrading or reflashing. Reflash the root, install the SD boot option and mirror the internal flash to the SD card as needed. I have chinook and diablo on my SD card, so I have three boot options for testing and development. Booting straight from SD card is less complex and gives you a better rescue-style option. Jason ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.so
On Wed, 20 Aug 2008, Darius Jack wrote: > any solution to a known problem ( a lot of entries in Google) > (Linux + mysql + php ) > mysql worked worked fine, testing mysql commands > to create a user with select, usage privileges on a tabase.* > and it worked > on shutdown > and reboot > can't run mysql > mysqld starts to run and stops, looking for a socket (none). Im guessing the fact the unix socket is in /tmp is a problem because /tmp is probably wiped during the boot process. Might be better off telling MySQL to use TCP sockets and bind to 127.0.0.1 instead. -- Aj. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Accessing RTSP streaming server via Nokia-N800
priyank kumar chourasia schrieb: > Hi, > > I am going to write a simple c++ based application for streaming a data > from remote server/Playing a file from local machine i.e. Nokia-N800, > I'll place the exe in Nokia-N800 which will be connected to a ubuntu > machine(Is in network) via USB network. > > - How can I stream a clip(from N800) which is located at the remote > server(for example rtsp://abc.com/abc.3gp) ?? > - What settings are required to perform the above task ?? gst-launch-0.10 playbin uri=rtsp://abc.com/abc.3gp Study gstreamer developer docs at gstreamer.freedesktop.org/docs/ if you want to do the same from a c or python app. If you have more questions, come to #gstreamer on freenode-irc. Stefan > > Regards, > Priyank > > > > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Busybox version
On Wednesday 20 August 2008 13:58:07 Marius Vollmer wrote: > I didn't really try to understand how you would be setting up the > various packges exactly, so I will only try to clarify the lock-down > mechanism a bit and ways to get around them. Thanks for the input, Marius. > What you refer to as "The Lock" is the osso-software-version-rx34 or > osso-software-verision-rx44 package which 'locks down' the set of > installed packages. It does this by depending on all individual > packages (with exact versions) that Nokia thinks that users should have > installed. OK. And is this package somehow involved in the notification of system upgrades to users? Does AppMgr treat it specially? If so, what makes it special? In addition, aren't there some locks around repositories that can be used to replace some (which?) packages? > We could provide a maemo-software-version-rx34, say, that is mostly > identical with osso-software-version-rx34 except that it uses a > different kernel, different busybox, coreutils, etc. Hmm. I am not keen on that idea -- it still doesn't allow the user flexibility in the combination of packages. > What about dpkg-divert, or just using Replace (without Conflict) to > overwrite the busybox symlinks from your package. I like the idea of using Replaces -- that had not occurred to me. We leave the system busybox package installed and can also install other packages that "Replaces: busybox" and include replacements for the appropriate subset of busybox links. So, for example, a gnu tar package could Replaces: busybox and install /bin/tar. A procps package could do the same. I am not certain what would happen when busybox was upgraded. I am not quite sure whether dpkg will restore the links to being owned by busybox or will honour the replacement. I presume it would continue to honour the replacement unless busybox also claimed Replaces: tar. This feels like it might work for installing the real utilities. For replacing busybox itself I am not sure it works so well -- there is a danger the busybox package could end up "disappeared" (see http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces), which would presumably cause the lock package to be either removed or broken. I haven't tried this so I don't know what would actually happen. There is also a potential problem when the replacing package is removed. Presumably the installed file is removed but busybox's link is not restored. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.so
Hi, any solution to a known problem ( a lot of entries in Google) (Linux + mysql + php ) mysql worked worked fine, testing mysql commands to create a user with select, usage privileges on a tabase.* and it worked on shutdown and reboot can't run mysql mysqld starts to run and stops, looking for a socket (none). Darius Send instant messages to your online friends http://uk.messenger.yahoo.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Location of /home, /tmp and /var folder kills tablet device in a couple of months
Frantisek wrote > See some explanation in > http://bugs.maemo.org/show_bug.cgi?id=598#c9 > > If you are concerned about this you can also boot whole system from > SD/MMC card - http://wiki.maemo.org/Booting_from_a_flash_card > Thank's for your answer. This clarifies a lot. Being able to use the device for about over 30 years is sufficient for me. But still i would like to know if it is save to move those directories to my external SD flash drive. I won't remove the SD drive on a daily basis, but i want to know when the system is mounting the SD flash drive because want be sure, that the device mounts the SD flash drive before accessing the files on these directories. So when does the system mount the device or when does it have access to it? This interests me also, because i want to move the /usr directory to the 2 GB internal flash drive because i need more space than 256 MB for user space programms. For example i want install a compiler + dev and documentation files on the device, that's why i will need the 2 GB for the software. So it is save to move those directories and changing the /etc/fstab entry or could this result in a problem booting the device? If the latter is the case, is there a way to rescue the system? Regards, Oliver -- GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Busybox version
Eero Tamminen <[EMAIL PROTECTED]> writes: > dpkg-divert requires modifying each package replacing anything from > Busybox, This sounds acceptable to me. > Maybe there could be a wiki page listing Busybox shortcomings? Let's get rid of busybox already. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Busybox version
Hi, 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. 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? Graham? - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Location of /home, /tmp and /var folder kills tablet device in a couple of months
Hi, ext Oliver wrote: > The /home, /tmp and /var folders are stored on the small internal 256 MB > flash device. > This is a problem, because writing to a flash device very often kills the > device. If you run the "mount" command, you'll notice that frequently used /tmp and /var/run directories are actually in tmpfs i.e. in RAM (which size is limited to 1/2MB, anything needing more space should use $TMPDIR i.e. /var/tmp). > So, i suggest to move the /var, /tmp and /home folders (and any other > folder with very variable data) to the flash SD memorycards because > they can be replaced anytime by new ones when they get unfunctional > someday. Having directories required in device bootup on a media that user can remove (and which isn't inserted in the device when user gets it out of the package) is not really a good idea for a consumer device. > So the /etc/fstab needs to be changed and filesystem on the external > SD card needs also to be changed from vfat to something more suitable > for a linux os. So something like JFFS2 or ext2/3. JFFS2 is for raw flash, not memory cards. Ext2/3 aren't recognized by Windows or Mac so most(?) users wouldn't be able to copy their media files on them. The cards are formatted as FAT when people buy them. > An experienced user might be able to do these changes on its own but unskilled tablet users won't be able to do this. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Location of /home, /tmp and /var folder kills tablet device in a couple of months
Oliver wrote: > The main problem here are for example the Browser Cache and E-mail directory > in /home > and other data that is stored in /tmp or /var. > This data all result in many write accesses to the internal flash device and > in the long term this will have the result that the Tablet can't store new > data on the internal flash device which makes the tablet useless. See some explanation in http://bugs.maemo.org/show_bug.cgi?id=598#c9 If you are concerned about this you can also boot whole system from SD/MMC card - http://wiki.maemo.org/Booting_from_a_flash_card Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Location of /home, /tmp and /var folder kills tablet device in a couple of months
Hello, The /home, /tmp and /var folders are stored on the small internal 256 MB flash device. This is a problem, because writing to a flash device very often kills the device. The main problem here are for example the Browser Cache and E-mail directory in /home and other data that is stored in /tmp or /var. This data all result in many write accesses to the internal flash device and in the long term this will have the result that the Tablet can't store new data on the internal flash device which makes the tablet useless. The bad thing about this is, that you can't replace this internal 268 MB flash device by a new one. So, i suggest to move the /var, /tmp and /home folders (and any other folder with very variable data) to the flash SD memorycards because they can be replaced anytime by new ones when they get unfunctional someday. (for the N810 only the flash card in the external slot can be replaced) So the /etc/fstab needs to be changed and filesystem on the external SD card needs also to be changed from vfat to something more suitable for a linux os. So something like JFFS2 or ext2/3. An experienced user might be able to do these changes on its own but unskilled tablet users won't be able to do this. So this change should be made primarly by the maemo project itself. That's why i suggest this change here on the mailinglist. What's your opionion about this topic, changing the /home /tmp and /var folder location to a location on a SD flash memorycard that can be replaced? Some people, especially N810 user might want to use their only external SD slot for exchanging data between a camera instead of using it for the system /home and /var folders. So this might be a small price loosing this feature but you win by a tablet device with a lot longer lifetime. Hint: Here does also a small solution exist for those people. It should be possible to put the USB port of the N810 device in host mode, so that those people can connect a SD flash memory reader USB stick to the N810 device. Regards, Oliver -- GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Busybox version
Hi! I didn't really try to understand how you would be setting up the various packges exactly, so I will only try to clarify the lock-down mechanism a bit and ways to get around them. (As to busybox itself, my gut tells me to just use coreutils etc in ITOS and eat the resource increase that this causes. If we get performance problems with shell scripts (because the coreutils are slower than busybox), we should consider rewriting them in Perl or C, together with Debian if we share them.) "ext Graham Cobb" <[EMAIL PROTECTED]> writes: > That is the killer. The whole point of this mechanism has to be that > it works WITHOUT removing the lock! What you refer to as "The Lock" is the osso-software-version-rx34 or osso-software-verision-rx44 package which 'locks down' the set of installed packages. It does this by depending on all individual packages (with exact versions) that Nokia thinks that users should have installed. The only point of doing this is to protect users from accidents. We don't try to satisfy any misguided security or legal requirements with this. So as long as we find an arrangement that keeps the risk of accidents low, anything goes. You seem to be asking for changes to the osso-software-version-foo meta packages so that they would allow some latitude for that installed packages. I don't think we should do that. Instead, we should provide additional, alternative meta packages that represent different configurations, and we should also improve our packages so that apt-get dist-upgrade actually works and to improve the Application manager so that it can do a dist-upgrade in the UI. We could provide a maemo-software-version-rx34, say, that is mostly identical with osso-software-version-rx34 except that it uses a different kernel, different busybox, coreutils, etc. We should also give people the chance to to live completely freely, without any meta packages that try to control their configuration, Debian style. Right now, I think this has a significant risk of killing your OS installation, unfortunately. > 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. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: border in osso-xterm in fullscreen?
Stefan Kost wrote: > Sounds good. Have you filed an enhancement request at > bugzilla.gnome.org? Should be easy to fix. Seems like this was reported year ago http://bugzilla.gnome.org/show_bug.cgi?id=471920 I have added comment. BTW if anyone cares about this you can get recompiled libvte for Diablo here http://www.internettablettalk.com/forums/showthread.php?p=211159#post211159 Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Linux kernel module autobuilding
On Tue, 2008-08-19 at 08:08 +0100, ext Faheem Pervez wrote: > Hi, > > Have you looked in the fuse source package that is on extras? That > uses the rules file to get the kernel and build the fuse module from > it. > I wouldn't recommend fuse module as an example. They're compiling whole kernel just to get one module. It's the same as compiling libc for 'hello, world' package :) I'd suggest to package preconfigured kernel sources as separate package and then use it as a build-dependency to your module. If you need my help with this - don't hesitate to ask. Br, -- Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
