[maemo-developers] Using XMPP URIs from Opera
Hi, I was just wondering whether it would be possible to use XMMP URIs (http://wiki.jabber.org/index.php/XMPP_URIs) from Opera to make a chat or voice call just by clicking a xmpp:// link on a web page? It should be possible by adding a line to the opera.ini file, but what application I should launch from there? osso-voip-ui? or something else? osso-voip-ui.launch seems to give a segmentation fault when run from the terminal. Regards, Teemu -- Teemu Harju http://www.teemuharju.net ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Repositories
On 9/5/06, Carlos Guerreiro <[EMAIL PROTECTED]> wrote: Most of these differences are not really justified anymore. Theexceptions (themes,bitmaps,...) need to be handled in a controlledmanner. We are working towards getting rid of the unnecessarydivergence. Well ... I am one of those users caught a bit by doing an "apt-get upgrade" (more specifically I took the Red Pill and upgraded some core packages) and expecting it to "do the right thing". I didn't get the constant rebooting but I am experiencing random application crashes now. "The right thing" that I was expecting was:- Upgrade core packages with newer more stable more up to date packages with possible security fixes and functionality fixes but no great leaps in versions - any unstable, in-development packages for the next version of the OS would be in a separate repository component that would need to be specificially enabled- once a new stable branch was developed, I could use apt-get upgrade to upgrade my 770 to it after changing the repository info over I understand now that the repositories are not arranged that way for the 770 ... I just wish they were.I also have to figure out which packages to downgrade in order for my 770 to become stable again. Maybe a reflash is the simplest way. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: Sardine build environment broken?
On Mon, 2006-09-04 at 18:51 +0300, Janne Kataja wrote: > Hello, > > I tried to apt-get dist-upgrade to latest sardine, but there was a > problem with missing libXfixes.so.0. Try 'apt-get upgrade' instead. This is what we've been running and is recommended here:http://repository.maemo.org/sardine/getting_started.html Sometimes packages are held back. Often (e.g. there are no missing dependencies) it is possible to install those with 'apt-get install'. > This is not listed in any dependencies, but it's linked to in many > binaries and libraries. I presume you did this inside an i386 scratchbox. Could you check again, this time with 'apt-get upgrade'? > Maybe this is a problem with the build environment? > What is this libxfixes supposed to do? http://www.freedesktop.org/wiki/Software_2fFixesExt > > ldd /usr/lib/libgtk-x11-2.0.so > .. > libXfixes.so.0 => not found (0x) > > > Janne > ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Sardine build environment broken?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carlos Guerreiro schreef: > I was able to upgrade it on a i386 scratchbox though I had to forcefully > install (dpkg --install --force-all) libbluetooth2 (a known problem). Bug #750 for the curious :) regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFE/dlMMkyGM64RGpERAjv0AJ9z+2Lt3+MkxeTZIeRFf+HdEQSZNQCdE1mg m9dy5lDPzzTC4BSRjD/OH7I= =LE4U -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: Sardine build environment broken?
On Tue, 2006-09-05 at 22:42 +0300, Carlos Guerreiro wrote: > On Mon, 2006-09-04 at 19:54 +0300, Tran Van Hoang wrote: > > Hi Carlos, > > > > Also, the dependency between hildon-fm-dev and hildon-fm1 is broken > > > > <-<-<-<-<-<-<-<-<- > > fakeroot apt-get install hildon-fm-dev > > Reading Package Lists... Done > > Building Dependency Tree... Done > > Some packages could not be installed. This may mean that you have > > requested an impossible situation or if you are using the unstable > > distribution that some required packages have not yet been created > > or been moved out of Incoming. > > > > Since you only requested a single operation it is extremely likely that > > the package is simply not installable and a bug report against > > that package should be filed. > > The following information may help to resolve the situation: > > > > The following packages have unmet dependencies: > > hildon-fm-dev: Depends: hildon-fm1 (= 1.7-1) but 1.6-1 is to be > > installed > > E: Broken packages > > ->->->->->->->->-> > > > > hildon-fm1 v 1.7-1 is not to be found > > > > This seems to be a problem in the q-manager for the sardine repository > or the caching network. > hildon-fm1 1.7-1.1 built fine and was uploaded to it. > If you look at http://repository.maemo.org/pool/sardine/main/o/osso- > gnomevfs-extra/ you'll see the armel package is actually there though > the i386 package isn't even though both were built and uploaded. > http://repository.maemo.org/sardine/i386/packagestatus.html > > I built the i386 package, and uploaded it manually to the repository. > Even though dput apparently succeeded I still can't see it in the > repository. > > Ferenc, maybe you can help with this? It looks like I was to quick to write that. hildon-fm1 1.7-1.1 now made it to the repository (the manual build I presume) I was able to upgrade it on a i386 scratchbox though I had to forcefully install (dpkg --install --force-all) libbluetooth2 (a known problem). In the end I could upgrade everything on a i386 scratchbox through 'apt- get upgrade' but also 'apt-get install' for some packages being held back. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Repositories
> ext Andrey Khurri wrote: > > > Hi all, > > > > I am now a bit puzzled with this repositories stuff. I've been always > > aware of that repository.maemo.org MUST NOT be used on a host > > workstation or PC. This is clear. > > > > However, how should I interpret all those warnings that this repository > > is 'ONLY' meant for using inside Scratchbox? This 'ONLY' sounds > > ambiguously to me when I look at i.e. ApplicationCatalog2006 and see > > there lots of packages meant for Nokia 770 device and available from > > repository.maemo.org. Doesn't this mean that repository.maemo.org should > > be included in /etc/apt/sources.list on Nokia 770 in order to get those > > packages installed? > > > > Or is the difference that one could fetch packages from > > repository.maemo.org and install them on Nokia 770 BUT could NOT use > > this repository to upgrade tablet (like 'apt-get upgrade')? > > > Correct. We need to look into organizing the repositories better > In most ideal and correct case, the apt-get upgrade from > repository.maemo.org should not do anything on the device so > validate perfect sync between packages on the device and packages > in the maemo repository. The problem starts from the fact that > maemo integration team takes these packages from internal package > repository for device and then > - reorganize them in a different (free/non-free) components then available > internally > - some source packages are cleaned to meet legal requirements (these cleanup > patches are filled as bugs in internal bugzilla, but sometimes not > applied internally > promptly, causing a different versions of binary packages produced) > - some device binary packages are replaced with packages delivered > specifically > for maemo e.g binary input method, themes, bitmaps, multimedia (codecs > etc) > Most of these differences are not really justified anymore. The exceptions (themes,bitmaps,...) need to be handled in a controlled manner. We are working towards getting rid of the unnecessary divergence. Br, Carlos ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Repositories
"ext Miko Nieminen" <[EMAIL PROTECTED]> writes: > 1) When application manager is restarted, all application launched by it It's the maemo-launcher, of course, not the application manager... ;) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] kernel code
ext Devesh Kothari wrote: > Guillem Jover wrote: > > >> On Sun, 2006-09-03 at 09:55:52 +0200, ext Koen Kooi wrote: >> >>> Kalle Vahlman schreef: >>> The version in IT2006 is >> http://repository.maemo.org/pool/mistral/non-free/k/kernel-source-2.6.16/ >> >>> Non-free !?!? >>> >> Right, could someone (Ferenc, Devesh?) please check and fix the contents >> of that repo? There's other packages which seem wrongly placed, like >> attr, bzip2, build-essential, etc. >> >> > This obviously needs to be fixed ! Ferenc any reason they ended up in > non-free part ? > Put it on my list of issues that need to be persued. Should plan as part > of Maemo 2.1 > This is something I have know for a while and this is planned to be fixed in the next release. We just haven't had time to check which packages are under incorrect component. We need to automate these checks to guarantee that packages are under correct component. This situation is due the fact that on one day some packages have been going out with sources and on the other day sources are dropped, and as an addition to this this database contains some stupid mistakes. So far we have been fighting with more serious problems to get stuff out and thus we haven't been able to pay attention to these "cosmetic" issues. Our way to divide packages in the repository goes so that if sources are available then the component is free and if sources are not available then it is non-free. If you have any other suggestions about how to divide packages into different components, please send suggestions. We have been thinking about division of free/contrib/non-free (in this contrib is something else than contrib repository), but we decided that free/non-free is enough. Sincerely, -- Miko Nieminen [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Application installer feature requests/suggestions
, >>I know that the repositories are the preferred method for >>installing packages, but after installing yesterday >20 >>(Hatari) packages "From file..." several times in succession >>(to test the packages I created), I started to wish for >>following features: > > Hmm, did you want to test the package itself, or how the AM deal with > it? Mainly the package, but also that I didn't screw up anything AM-wise. :-) > If you just want to test the package, I would recommend getting a > shell and just using dpkg. You can install multiple packages with one > invocation of dpkg, for example. > >>- Application installer remembering from which directory >> the last file was selected and opening the filesel >> to the same dir next time (can be forgotten at >> application exit) > > Yep, that should be fixed. > > >>- After installing one file, application installer asking >> with a dialog either: >> - "Install another package from file? [OK] [Cancel]" >>(so that I don't need to use the menus each time as that's >> 3 clicks of differents keys instead of 1 additional select >> click), or > > No, I think that would be too intrusive for the normal use case. We > could add this feature for red-pill mode, tho. Patches welcome! :) > >> - "Add this directory as a package repository? [OK] [Cancel]" >>(so that if I use the same MMC directory for transferring >> more packages, I don't need to anymore use the fsel) > > That would be the proposed "dir://" method for apt: it would create > the needed Packages file on the fly. Can it also update the package list later on when doing "update"? (if I have added new packages to the dir in the meanwhile) One solution would be to have both of these alternatives: "Do you want to add this directory as a repository, or install another package from file? [Add repository] [Install] [Cancel]" >>Btw. I also tried adding "file:///media/mmc1/atari" as a repository >>(+ disabling the other tableteer repo), but when I refreshed >>the package list, Application installer disappeared. > > Whoops. Please file a bug about this. If it repeats... - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Repositories
ext Devesh Kothari wrote: > ext Andrey Khurri wrote: > > >> Hi all, >> >> I am now a bit puzzled with this repositories stuff. I've been always >> aware of that repository.maemo.org MUST NOT be used on a host >> workstation or PC. This is clear. >> >> However, how should I interpret all those warnings that this repository >> is 'ONLY' meant for using inside Scratchbox? This 'ONLY' sounds >> ambiguously to me when I look at i.e. ApplicationCatalog2006 and see >> there lots of packages meant for Nokia 770 device and available from >> repository.maemo.org. Doesn't this mean that repository.maemo.org should >> be included in /etc/apt/sources.list on Nokia 770 in order to get those >> packages installed? >> >> Or is the difference that one could fetch packages from >> repository.maemo.org and install them on Nokia 770 BUT could NOT use >> this repository to upgrade tablet (like 'apt-get upgrade')? >> >> Personally, I think that it would be very logical that you can use maemo repositories with your device. Like you said, these repositories contains a lot of application which are mend to be used on the device (maemo-dm, nfs client modules, ssh, etc...). I think that one of the major causes to this whole mess was that the use of these repositories at the device was too obvious and we never tested what happens in that case. Now I am quite embarrassed about this mess, but I have learned my lesson. Second lesson I learned was that think more when doing code-clean-ups. This caused the mess with constant reboot cycles, because I broke gst-plugings-farsight package. For my defense, I could say that I didn't have that much time to do those clean-ups and we needed those sources out. By the way fixed gst-plugins-farsight package is now at the repository. > Correct. We need to look into organizing the repositories better > In most ideal and correct case, the apt-get upgrade from > repository.maemo.org should not do anything on the device so > validate perfect sync between packages on the device and packages > in the maemo repository. The problem starts from the fact that > maemo integration team takes these packages from internal package > repository for device and then > - reorganize them in a different (free/non-free) components then available > internally > This doesn't cause any problems. > - some source packages are cleaned to meet legal requirements (these cleanup > patches are filled as bugs in internal bugzilla, but sometimes not > applied internally > promptly, causing a different versions of binary packages produced) > This is a major problem and in the future this should be fixed and there shouldn't be any problems related to this. > - some device binary packages are replaced with packages delivered > specifically > for maemo e.g binary input method, themes, bitmaps, multimedia (codecs > etc) > > This shouldn't cause any problems, if dependencies of these packages are properly defined. > >From this repo, then the developer rootfs is produced, in idea case, > apt-upgrade on > this developer rootfs should be OK. > > There is also this binary-only tar.gz package which contains some packages which are needed for the rootfs and it is distributed under EUSA (I hope this is the correct acronym) and can be downloaded from: http://www.maemo.org/downloads/d2.php >> I was also thinking that any package installable inside SB environment >> (in an armel target) can be installed on Nokia 770? If this is right can >> the same repositories be used both inside SB and on N770? >> >> > The problem is with upgrade :( I have put this on the agenda to be > discussed and fixed. > In the future this issue should be fixed. There are two problems: 1) When application manager is restarted, all application launched by it are terminated and thus there are processes which are system critical processes which will be killed. When any of these is terminated then lifeguard service will reboot the device in the middle of upgrade process (this is a bit simplified explanation). 2) When we do clean-ups and sdk specific fixes, we will change the version number and this will cause unnecessary upgrade of packages. If such package contains a system critical application it might cause device to reboot in the middle of upgrade. First problem should be fixed quite soon and it's possible that the fix for this already exists at the sardine, I'm not sure. The second problem should be fixed so that we don't need to do sdk specific fixes and clean-ups and I strongly believe that this issue will be fixed in the next sdk release. If you upgrade system critical applications then you should disable lifeguard before that. This can be done with command "/path/to/flasher-2.0 --set-rd-flags=no-lifeguard-reset". After this you should run "apt-get upgrade" and reboot the device. We really have learned a lesson over here and I hope we won't make these same mistakes again, if we do we wouldn't be very smart :-) br, -- Miko Niemine
Re: [maemo-developers] Application installer feature requests/suggestions
"ext Eero Tamminen" <[EMAIL PROTECTED]> writes: > I know that the repositories are the preferred method for > installing packages, but after installing yesterday >20 > (Hatari) packages "From file..." several times in succession > (to test the packages I created), I started to wish for > following features: Hmm, did you want to test the package itself, or how the AM deal with it? If you just want to test the package, I would recommend getting a shell and just using dpkg. You can install multiple packages with one invocation of dpkg, for example. > - Application installer remembering from which directory > the last file was selected and opening the filesel > to the same dir next time (can be forgotten at > application exit) Yep, that should be fixed. > - After installing one file, application installer asking > with a dialog either: > - "Install another package from file? [OK] [Cancel]" > (so that I don't need to use the menus each time as that's > 3 clicks of differents keys instead of 1 additional select > click), or No, I think that would be too intrusive for the normal use case. We could add this feature for red-pill mode, tho. Patches welcome! :) > - "Add this directory as a package repository? [OK] [Cancel]" > (so that if I use the same MMC directory for transferring > more packages, I don't need to anymore use the fsel) That would be the proposed "dir://" method for apt: it would create the needed Packages file on the fly. > Btw. I also tried adding "file:///media/mmc1/atari" as a repository > (+ disabling the other tableteer repo), but when I refreshed > the package list, Application installer disappeared. Whoops. Please file a bug about this. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
