[maemo-developers] kernel code
http://maemo.org/maemowiki/HowTo_KernelCompilation?highlight=%28kernel%29#co mpilation This how-to seems out of date. I was unable to get the kernel-source-2.6.12.3. Does anyone know the correct version or how I could find it? Thanks. E ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Answer discovered @ http://qstream.org/viewcvs/trunk/qvid/src/video_out/maemo_dsp_yuv/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The codec is a homegrown variant of MPEG-4 I call SPEG. Basically SPEG adds fine granularity SNR scalability to MPEG-4. SPEG is part of a larger overall project on quality-adaptive video streaming. The SPEG implementation is derived from from the xvid code base. You can find all of my code, including the modified xvid, and the rest of the streaming system, along with instructions on how to build the system at http://qstream.org. For the last month or so, I have been working on porting the qstream client to the Nokia 770. The actual streaming video part of the port is working very well now. In terms of actual video/streaming, I think it already does much better than the bundled player. Before I actually cut the first release, it needs some more testing, as well as all of the hildon gui stuff (which I plan to do with PyGtk), and proper deb packaging. I hope to get that done in a few weeks. If you are actually serious about trying the codec, I'd be happy to try and help you in any way I can. - -- Buck Ed Okerson wrote: > What video codec are you trying to use? Maybe I can try my hand at > it. > > Ed > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE+JlwPrrWIMa4SMsRAtUyAKDjitFiEyz21ukYGgvMwKN7M4bGpgCZAc7D Ri3ZbFaq7TPBPVvSGT07nbY= =rMw7 -END PGP SIGNATURE- begin:vcard fn:Charles 'Buck' Krasic n:Krasic;Charles 'Buck' org:University of British Columbia;Department of Computer Science adr:;;201-2366 Main Mall;Vancouver;B.C.;V6T 1Z4;Canada email;internet:[EMAIL PROTECTED] title:Assistant Professor tel;work:(604) 822-5628 tel;fax:(604) 822-5485 tel;cell:(604) 313-9429 x-mozilla-html:FALSE url:http://www.cs.ubc.ca/~krasic/ version:2.1 end:vcard ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Answer discovered @ http://qstream.org/viewcvs/trunk/qvid/src/video_out/maemo_dsp_yuv/
What video codec are you trying to use? Maybe I can try my hand at it. Ed > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I didn't know how easy using the LCD hardware support for YUV was when > I started working on this. > > Later on, when I did figure that out (when a Nokian finally posted > something to the list), I revised my DSP code to do scaling only > (YUV->YUV). Even that was too slow on the DSP. One issue I never > resolved was how to get the DSP to write directly to the framebuffer > memory.I got it partially working, but I think I was hitting some > variant of the 64k issue (see next paragraph). So in the end, I > reverted to having the DSP copy the scaled video to memory shared with > the MPU, and then the MPU would copy it to the framebuffer. > > Although the DSP tools include a C compiler, there are issues that > make porting existing C code far from trivial. For starters, the > fact that byte size on the DSP is 16 bits makes for a lot of grief. > The other issue that kicked me in the teeth is that the DSP can not > deal with data objects > 64kbytes (1 DSP page). Actually, my > impression is that this is not true anymore of the OMAP 1710 in the > 770, but the free DSP tools are quite old and actually targetted to an > older revision of the DSP, so the C compiler does not contain later > revisions that removed that limitation. I surmise that if I > purchased an up to date CCS, this would have been fixed. In > hindsight, I should probably have done that. As it was, I had to > write some very ugly code to work around that 64k issue.The > workaround code probably is not without performance penalty either. > > My code is available in the maemo_dsp_yuv in case anyone wants to > suggest how it might be improved.My impression is that truly > peformant DSP code requires a lot of actual expertise on the DSP > architecture, including the ability to hand tune DSP assembly for the > critical code. I don't have the time to learn how to do that. > > Since I wasn't able to get a relatively simple task like YUV->YUV > scaling to run with adequate speed on the DSP, I'm far from optimistic > that porting my video codec to the DSP will be a fruitful exercise. > > - -- Buck > > > Ed Okerson wrote: > >> If you have gone so far as to implement the YUV to RGB conversion, >> why not go ahead and implement your codec on the DSP? You will get >> much better throughput. For that matter why not send the YUV >> directly to the display controller and let it do the RGB conversion >> in hardware? >> >> Ed >> > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.5 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFE+IT9PrrWIMa4SMsRAuBJAJ9qcUq7LYEFEMYJqmuLAajWuUAneQCgosWr > mtCyGPj8AdBJRuKIGUnMYqQ= > =5qMN > -END PGP SIGNATURE- > > ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Answer discovered @ http://qstream.org/viewcvs/trunk/qvid/src/video_out/maemo_dsp_yuv/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I didn't know how easy using the LCD hardware support for YUV was when I started working on this. Later on, when I did figure that out (when a Nokian finally posted something to the list), I revised my DSP code to do scaling only (YUV->YUV). Even that was too slow on the DSP. One issue I never resolved was how to get the DSP to write directly to the framebuffer memory.I got it partially working, but I think I was hitting some variant of the 64k issue (see next paragraph). So in the end, I reverted to having the DSP copy the scaled video to memory shared with the MPU, and then the MPU would copy it to the framebuffer. Although the DSP tools include a C compiler, there are issues that make porting existing C code far from trivial. For starters, the fact that byte size on the DSP is 16 bits makes for a lot of grief. The other issue that kicked me in the teeth is that the DSP can not deal with data objects > 64kbytes (1 DSP page). Actually, my impression is that this is not true anymore of the OMAP 1710 in the 770, but the free DSP tools are quite old and actually targetted to an older revision of the DSP, so the C compiler does not contain later revisions that removed that limitation. I surmise that if I purchased an up to date CCS, this would have been fixed. In hindsight, I should probably have done that. As it was, I had to write some very ugly code to work around that 64k issue.The workaround code probably is not without performance penalty either. My code is available in the maemo_dsp_yuv in case anyone wants to suggest how it might be improved.My impression is that truly peformant DSP code requires a lot of actual expertise on the DSP architecture, including the ability to hand tune DSP assembly for the critical code. I don't have the time to learn how to do that. Since I wasn't able to get a relatively simple task like YUV->YUV scaling to run with adequate speed on the DSP, I'm far from optimistic that porting my video codec to the DSP will be a fruitful exercise. - -- Buck Ed Okerson wrote: > If you have gone so far as to implement the YUV to RGB conversion, > why not go ahead and implement your codec on the DSP? You will get > much better throughput. For that matter why not send the YUV > directly to the display controller and let it do the RGB conversion > in hardware? > > Ed > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE+IT9PrrWIMa4SMsRAuBJAJ9qcUq7LYEFEMYJqmuLAajWuUAneQCgosWr mtCyGPj8AdBJRuKIGUnMYqQ= =5qMN -END PGP SIGNATURE- begin:vcard fn:Charles 'Buck' Krasic n:Krasic;Charles 'Buck' org:University of British Columbia;Department of Computer Science adr:;;201-2366 Main Mall;Vancouver;B.C.;V6T 1Z4;Canada email;internet:[EMAIL PROTECTED] title:Assistant Professor tel;work:(604) 822-5628 tel;fax:(604) 822-5485 tel;cell:(604) 313-9429 x-mozilla-html:FALSE url:http://www.cs.ubc.ca/~krasic/ version:2.1 end:vcard ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Answer discovered @ http://qstream.org/viewcvs/trunk/qvid/src/video_out/maemo_dsp_yuv/
If you have gone so far as to implement the YUV to RGB conversion, why not go ahead and implement your codec on the DSP? You will get much better throughput. For that matter why not send the YUV directly to the display controller and let it do the RGB conversion in hardware? Ed > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > I spent a lot of time searching for freely available tools and > information about the dsp. > > Maybe I can help you avoid duplicating my effort. I've put together > the various bits I collected here: > >http://qstream.org/770/dsp/ > > Mind the various readme files about copyrights, I re-distribute these > only as a convenience. Note, they are all freely available from > their original sources. > > - -- Buck > > To help save you the time of duplicating my effort > > Shae Matijs Erisson wrote: > >> Ok, sorry to bother you. Someone else on #maemo turned up this url >> http://qstream.org/viewcvs/trunk/qvid/src/video_out/maemo_dsp_yuv/ >> And that includes the answer to my question. > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.5 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFE+GWEPrrWIMa4SMsRAkyTAKDie4CbL59CXgN/V9MQ20JwBrT2FACfXt1C > OUXKfOrLRXMv3XFnZk7QmdQ= > =xzZ1 > -END PGP SIGNATURE- > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Answer discovered [ CORRECTION ]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Doh, I hit send too fast. The correct link is: http://qstream.org/~krasic/770/dsp/ - -- Buck Charles 'Buck' Krasic wrote: > Hi, > > I spent a lot of time searching for freely available tools and > information about the dsp. > > Maybe I can help you avoid duplicating my effort. I've put together > the various bits I collected here: > > http://qstream.org/770/dsp/ > > Mind the various readme files about copyrights, I re-distribute these > only as a convenience. Note, they are all freely available from > their original sources. > > -- Buck > > To help save you the time of duplicating my effort > > Shae Matijs Erisson wrote: > > >Ok, sorry to bother you. Someone else on #maemo turned up this url > >http://qstream.org/viewcvs/trunk/qvid/src/video_out/maemo_dsp_yuv/ > >And that includes the answer to my question. > > > ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE+GYfPrrWIMa4SMsRAoPnAJ9cG28OuiogIZSsCa7JwkufgllWwQCgzSuJ vNKvgV/Y6eH3XIOBV4LUOEQ= =4z8T -END PGP SIGNATURE- begin:vcard fn:Charles 'Buck' Krasic n:Krasic;Charles 'Buck' org:University of British Columbia;Department of Computer Science adr:;;201-2366 Main Mall;Vancouver;B.C.;V6T 1Z4;Canada email;internet:[EMAIL PROTECTED] title:Assistant Professor tel;work:(604) 822-5628 tel;fax:(604) 822-5485 tel;cell:(604) 313-9429 x-mozilla-html:FALSE url:http://www.cs.ubc.ca/~krasic/ version:2.1 end:vcard ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: Answer discovered @ http://qstream.org/viewcvs/trunk/qvid/src/video_out/maemo_dsp_yuv/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I spent a lot of time searching for freely available tools and information about the dsp. Maybe I can help you avoid duplicating my effort. I've put together the various bits I collected here: http://qstream.org/770/dsp/ Mind the various readme files about copyrights, I re-distribute these only as a convenience. Note, they are all freely available from their original sources. - -- Buck To help save you the time of duplicating my effort Shae Matijs Erisson wrote: > Ok, sorry to bother you. Someone else on #maemo turned up this url > http://qstream.org/viewcvs/trunk/qvid/src/video_out/maemo_dsp_yuv/ > And that includes the answer to my question. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE+GWEPrrWIMa4SMsRAkyTAKDie4CbL59CXgN/V9MQ20JwBrT2FACfXt1C OUXKfOrLRXMv3XFnZk7QmdQ= =xzZ1 -END PGP SIGNATURE- begin:vcard fn:Charles 'Buck' Krasic n:Krasic;Charles 'Buck' org:University of British Columbia;Department of Computer Science adr:;;201-2366 Main Mall;Vancouver;B.C.;V6T 1Z4;Canada email;internet:[EMAIL PROTECTED] title:Assistant Professor tel;work:(604) 822-5628 tel;fax:(604) 822-5485 tel;cell:(604) 313-9429 x-mozilla-html:FALSE url:http://www.cs.ubc.ca/~krasic/ version:2.1 end:vcard ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Red pill mode for the Application Manager
Hi, I just documented the mysterious red pill mode of the Application Manager in the Wiki: http://maemo.org/maemowiki/ApplicationManagerRedPillMode I think it is too useful to just keep it as an in-joke. Please spread the information. There is one new feature in the Sardine AM that I want to point out especially: the "Show magic system package" setting. It will allow you to do something like "apt-get upgrade". Please try it out! ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: rebooting constantly after upgrading packages
On Fri, 2006-09-01 at 15:05 +0200, ext Johannes Eickhold wrote: > Am Freitag, den 01.09.2006, 15:18 +0300 schrieb Kuosmanen Tuomas > (Nokia-M/Helsinki): > > There is one important thing to remember: Just because it has apt-get, > > does not mean it *IS Debian*. Assuming it works like debian in every > > sense will be a bad mistake currently. It contains stuff and tools from > > debian, but it's not the same thing. > > Sorry, but it is a bad idea [tm] to deliver a tool thousands of people > (users of debian-based distros) are used to work with on a daily basis > and then tell them it behaves different here and should NOT AT ALL be > used. I think it should be noted that how reliably apt-get works even on real Debian installation depends very much on which repositories are configured. -- Tommi Komulainen<[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: rebooting constantly after upgrading packages
On Thu, 31 Aug 2006, Michael Flaig did have cause to say: > Oh and just a hint: I installed some packages from unofficial repos (but > listed in the wiki) that seemed to have broken the dpkg status file on my > 770.. Quickest way to fix this was making backup and reflashing :-( > .o(Note to myself: You need to verify this ...) Manual editing of the status file can solve this. I've had it get corrupted several times (lost the "itit" off an i18n package, so it complained about the package having no files.. added random garbage chars in place of the version of another package, etc..) Also, if you catch it immediately, status.old should still be a (mostly) valid version, sans whatever changes were made that caused it. So you can use that as a reference when recreating the file. All this lives in /usr/lib/dpkg IIRC (or /var/lib/dpkg?) > > Cheers, > > Michael > > - Original Message - > From: Sebastian Spaeth <[EMAIL PROTECTED]> > To: maemo-developers@maemo.org > Sent: Thursday, August 31, 2006 9:22:03 PM GMT+0100 > Subject: [maemo-developers] Re: rebooting constantly after upgrading packages > > Michael Flaig wrote: > > afaik apt-get upgrading isn´t meant for consumers. > > Remember, you read the info about rd mode and breaking the device ... > > I would agree with your assessment if I were running sardine. I would > expect frequent breakages and I would expect that I would have to figure > out the source of these on my own. However, I am only running the > "stable" repositories so far. So compare that to debian (on which this > thing is based): If I update the stable distribution and it breaks for a > lot of people, wouldn't you expect someone to upgrade/revert that > package? As simple apt-get upgrade should be expected by users who are > told this thing is debian based. > > As for rd-mode: I haven't enabled it, so I guess i am still within the > reach of what you would expect of regular (power-)consumers. Heck, that > tableteer website even advertizes the additional programs from the > repositories, so I guess consumers are supposed to install and update stuff! > > > But I absolutly agree that these packages need to be removed or fixed. > > Hopefully someone at nokia will do it for us. > > We are on the same side on this one :-) > > Cheers, > Spaetz > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers > > !DSPAM:16,44f75a11279905981814949! > ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: rebooting constantly after upgrading packages
"ext Johannes Eickhold" <[EMAIL PROTECTED]> writes: > Sorry, but it is a bad idea [tm] to deliver a tool thousands of people > (users of debian-based distros) are used to work with on a daily basis > and then tell them it behaves different here and should NOT AT ALL be > used. Nonono, that is not what is being said. The official position at this point in time is that you should not expect the maemo 2.0 mistral repository to work with your device. You can say this happened because of some traditional ideas about what an SDK is. The SDK really is meant only for cross-compiling stuff in Scratchbox, and the repositories that are made available with it are also only _required_ to work for cross-compiling in Scratchbox. Now, the maemo 2.0 mistral repository _nearly_ works when used on the device. From a bureaucratic point of view that is an unexpected extra bonus. From the point of a Debian-seasoned person, it's embarassing und not really understandable that it doesn't work _completely_. But expect us to improve! ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: rebooting constantly after upgrading packages
Am Freitag, den 01.09.2006, 15:18 +0300 schrieb Kuosmanen Tuomas (Nokia-M/Helsinki): > On Fri, 2006-09-01 at 09:26 +0200, ext Rainer Dorsch wrote: > > I appreciate that apt-get is there. It allows me to login into the device > > from > > my PC and work with the device like I am used to from debian or ubuntu > > boxes. > > There is one important thing to remember: Just because it has apt-get, > does not mean it *IS Debian*. Assuming it works like debian in every > sense will be a bad mistake currently. It contains stuff and tools from > debian, but it's not the same thing. Sorry, but it is a bad idea [tm] to deliver a tool thousands of people (users of debian-based distros) are used to work with on a daily basis and then tell them it behaves different here and should NOT AT ALL be used. I wonder what your options are... 1. Change the situation and make apt-get upgrade usable by providing sane stable packages in repository.maemo.org which are always usable on the device too. 2. Provide a different repository which only contains packages meant to be installed on the device. 3. Patch apt-get to refuse to work when the upgrade option is given. There are a number of pros and cons attached to these options and probably there are even more. Jonek [tm] http://www.netzmafia.de/skripten/netze/etherkiller.jpg ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: rebooting constantly after upgrading packages
On Fri, 2006-09-01 at 09:26 +0200, ext Rainer Dorsch wrote: > I appreciate that apt-get is there. It allows me to login into the device > from > my PC and work with the device like I am used to from debian or ubuntu boxes. There is one important thing to remember: Just because it has apt-get, does not mean it *IS Debian*. Assuming it works like debian in every sense will be a bad mistake currently. It contains stuff and tools from debian, but it's not the same thing. I agree it would be good if it was more compatible, as many people expect that. //Tuomas -- A: No Q: Should i quote this on the top? ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: rebooting constantly after upgrading packages
ext Álvaro J. Iradier <[EMAIL PROTECTED]> writes: > What's the difference between apt-get upgrading and using the > application manager "search for updates" option? I thought it was the > same... No, not exactly. What the Application manager does is more similar to "apt-get install". It will not upgrade the system packages automatically theway "apt-get upgrade" does. > If upgrading is not meant for consumers, why is that broken package in > the maemo repository? Shouldn't it be in sardine? I mean, what's the > point on having updated packages? You are spot on. This is chaos and the mistral repositories should not contain the broken packages. They need to be fixed and/or reverted to the same version that is in the IT2006 flash image. People here are aware of this... (and also appropriately embarrassed). ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Problems installing Sardine SDK
Hi, I tried to install sardine distro in a scratchbox target. First thing that has gone wrong was libbluetooth1 and i had to force it fakeroot dpkg -i --force-all libbluetooth1_3.1_i386.deb After that the upgrade went fine. Now i could not start the Control Panel. I installed hildon-control-panel-2.2.5-1 Below is what i see when i try to start control panel from task navigator. hn-wm.c:265,hn_wm_top_service() Called with 'com.nokia.controlpanel' hn-wm.c:299,hn_wm_top_service() ### Failed to read memory limits, using scratchbox ?? hn-wm.c:332,hn_wm_top_service() unable to find service name 'com.nokia.controlpanel' in running wins hn-wm.c:333,hn_wm_top_service() Thus launcing via osso_manager_launch() hn-wm.c:1493,hn_wm_dbus_method_call_handler() Checking if service: 'com.nokia.controlpanel' is watchable hn-wm.c:1502,hn_wm_dbus_method_call_handler() Showing Launchbanner... Home applet are working but the statusbar does not seem to work. Calling the line below does nothing. dbus-send --session --type=method_call --dest=com.nokia.statusbar /com/nokia/statusbar com.nokia.statusbar.event string:helloworld int32:1 int32:0 string: Could someone help me with these problems. Thank you ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: rebooting constantly after upgrading packages
Hello, Am Freitag, 1. September 2006 08:31 schrieb Andrey Khurri: > Hello, > > It is interesting to see that a post initiated by me due to cycle reboot > after upgrading has grew into such a big thread. It seems that this > problem has been experienced by a lot of people and has annoyed them. > This is true. True for me too. > I absolutely agree that either using Application Manager or apt-get tool > to upgrade the system must NOT brake it at any point. > As for apt-get and consumers I believe that this command tool is pretty > nice to use in a Debian like system and it is meant for end users as > well as any graphical package manager. I appreciate that apt-get is there. It allows me to login into the device from my PC and work with the device like I am used to from debian or ubuntu boxes. Thanks, Rainer > Some notes on rd-mode see below... > > Michael Flaig wrote: > > Hi Sebastian, > > > > you probably got me wrong on the first part ... I agree with you. Just > > wanted to point out that in my opinion there is no official support for > > xterm + apt-get with mistral. With application installer this problem > > doesn´t happen, because it doesn't update system packages only apps. > > > > I also agree with you that maemo should be more debian-like and debian > > tools should work flawlessly... > > > > What I know of this problem and fixes, so far... > > 1) the problem with upgrading a running maemo-launcher seems to be fixed > > in sardine 2) I have not read anything new of the gstreamer issue, which > > seem to cause these reboot cycles, too. 3) So far no information what > > this gstramer module which you need to remove does > > > > You wrote that you didn´t enable rd mode: How did you apt-get then? I´m > > thought that apt-get is only available for root (sudo gainroot) and not > > for the user. becomeroot package? Do I miss anything? > > Using apt-get needs root privileges, that is right. However, if you are > using 'sudo gainroot' you might and should disable rd-mode after editing > /usr/sbin/gainroot file (in order to get 'sudo gainroot' working later > without rd-mode) as HOWTO proposed > http://maemo.org/maemowiki/HowDoiBecomeRoot > > Myself I am using 'sudo su' (the easier way to get root access) and this > is working ok for me http://maemo.org/maemowiki/HowDoiBecomeRoot2 > > > I've put the N770 in rd mode since IT2006 beta, so I could be wrong. > > > > Oh and just a hint: I installed some packages from unofficial repos (but > > listed in the wiki) that seemed to have broken the dpkg status file on my > > 770. Quickest way to fix this was making backup and reflashing :-( > > .o(Note to myself: You need to verify this ...) > > > > Cheers, > > > > Michael > > Cheers, > Andrey > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers -- Rainer Dorsch Alzentalstr. 28 D-71083 Herrenberg 07032-919495 Icq: 32550367 GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
