RE: MeeGarage ?
> -Original Message- > From: ext archebyte . [mailto:archeb...@gmail.com] > Sent: 16 February, 2010 15:04 > To: Kojo Tero (Nokia-D/Helsinki) > Cc: ma...@csipa.in.rs; maemo-developers@maemo.org > Subject: Re: MeeGarage ? > > > > > Could you post an exact link to where you see the merge info? > > http://meego.com/garage > "Right now, we are working on merging the two garages, but it's not > quite ready (there's a lot of cool stuff!) Check back soon." Thanks, I can't understand how I missed that. I did read the page when I saw the first mail in this thread. Anyhow, it's corrected now. Tero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: TreeView with variable height rows?
On Tue, Feb 16, 2010 at 9:29 AM, Luca Donaggio wrote: > I'm trying to add a multi-line text to a TreeViewColumn using the "markup" > property of a standard CellRendererText; > The text is correctly word-wrapped so that it spans on multiple lines, but > the problem is that the treeview row's height seems to be fixed - ie the > text displayed is truncated horizontally and rows doesn't expand to > accomodate it. > > Is there a way to achieve this using a standard CellRendererText or do I > need to create my own CellRenderer? > I'd avoid that if possible, as I don't need any fancy stuff apart from that > already offered by pango markup. I recommend looking at the history in the following bug https://bugs.maemo.org/show_bug.cgi?id=6864 Ed Page ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: diablo autobuilder problem
2010/2/16 ds : > Some minutes ago this worked: > > https://garage.maemo.org/builder/diablo/vncviewer_0.6.6-fremantle1/armel.build.log.OK.txt > > checking for intltool >= 0.23... 0.35.0 found > > > > a little bit later with minor changes (which I even tried to reverse) > > > https://garage.maemo.org/builder/diablo/vncviewer_0.6.6-fremantle5/armel.build.log.FAILED.txt > > > checking for intltool >= 0.23... ./configure: line 1: intltool-update: > command not found > found > configure: error: Your intltool is too old. You need intltool 0.23 or later. > > > did not work anymore. > > > Any idea, what happend? > Looks very strange that it was built successfully. With current configuration it shouldn't happen, unless somebody just changed it. intltool-update comes from doctools devkit, which is not enabled for Diablo builds. Unfortunately I don't have permissions to change configuration files on the builder box. Niels, can you enable doctools devkit in /etc/sbdmock/maemo-diablo-*.cfg? -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
diablo autobuilder problem
Some minutes ago this worked: https://garage.maemo.org/builder/diablo/vncviewer_0.6.6-fremantle1/armel.build.log.OK.txt checking for intltool >= 0.23... 0.35.0 found a little bit later with minor changes (which I even tried to reverse) https://garage.maemo.org/builder/diablo/vncviewer_0.6.6-fremantle5/armel.build.log.FAILED.txt checking for intltool >= 0.23... ./configure: line 1: intltool-update: command not found found configure: error: Your intltool is too old. You need intltool 0.23 or later. did not work anymore. Any idea, what happend? Thanks a lot Detlef ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Porting Yum to N900?
While there is no 'need' to have yum installed, at least on some of my x86 based ubuntu boxes I have found it useful to have, and seem to recall installing various packages using yum under Ubuntu. I do not recall running into any dependency issues, but it was a while ago that I did this. It does show up nicely in my cache on my x86 based ubuntu machines, and I've installed it using apt, but I don't see any way of doing that (yet) on the N900. As to waiting for MeeGo to be available for the N900, that may be a good while yet, and for most people it may be a wise idea to wait, but I always enjoy looking for ways to push the envelope. Aldon -Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers-boun...@maemo.org]on Behalf Of Christopher Intemann Sent: Tuesday, February 16, 2010 1:57 PM To: maemo-developers Subject: Re: Porting Yum to N900? Since Maemo is still based on Debian, there is actually no need to have yum installed even though there seems to exist a port to Debian/x86: apt-cache search yum yum - Advanced front-end for rpm However, I really don't know how yum would handle missing dependencies, which it will find in any case, since even installed libs will probably not be registered in the rpmdb, nor would a rpm -initdb command help. Therefore rpms can probably only be installed on Debian by either using rpm -f or double install the dependent files as rpm as well. Just my thought, though, I never tried to mix both deb and rpm, but I'd like to know as well... maybe it is possible to create a rpm DB from the deb DB, but I hardly doubt that. I'd rather wait for MeeGo becoming available for the N900 and having switched to rpm than polluting my device with packages from different architectures, though. Cheers, Chris On Tue, Feb 16, 2010 at 6:57 PM, Aldon Hynes wrote: Personally, I'm agnostic in the rpm v. deb wars. Most of my boxes end up supporting apt and I use that most of the time, but I've used yum at times as well and from my perspective they both seem fine. That said, I don't see yum as an available package on the N900. Has anyone ported it? Does anyone have any RPM packages for the N900? Personally, instead of arguing back and forth, I'd like to see this made available. I like giving users choices and I'd love to see yum as a viable choice on the N900 My two cents. Aldon ___ 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: Porting Yum to N900?
Since Maemo is still based on Debian, there is actually no need to have yum installed even though there seems to exist a port to Debian/x86: apt-cache search yum yum - Advanced front-end for rpm However, I really don't know how yum would handle missing dependencies, which it will find in any case, since even installed libs will probably not be registered in the rpmdb, nor would a rpm -initdb command help. Therefore rpms can probably only be installed on Debian by either using rpm -f or double install the dependent files as rpm as well. Just my thought, though, I never tried to mix both deb and rpm, but I'd like to know as well... maybe it is possible to create a rpm DB from the deb DB, but I hardly doubt that. I'd rather wait for MeeGo becoming available for the N900 and having switched to rpm than polluting my device with packages from different architectures, though. Cheers, Chris On Tue, Feb 16, 2010 at 6:57 PM, Aldon Hynes wrote: > Personally, I'm agnostic in the rpm v. deb wars. Most of my boxes end up > supporting apt and I use that most of the time, but I've used yum at times > as well and from my perspective they both seem fine. > > That said, I don't see yum as an available package on the N900. Has anyone > ported it? Does anyone have any RPM packages for the N900? Personally, > instead of arguing back and forth, I'd like to see this made available. I > like giving users choices and I'd love to see yum as a viable choice on the > N900 > > My two cents. > > Aldon > > ___ > 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
Porting Yum to N900?
Personally, I'm agnostic in the rpm v. deb wars. Most of my boxes end up supporting apt and I use that most of the time, but I've used yum at times as well and from my perspective they both seem fine. That said, I don't see yum as an available package on the N900. Has anyone ported it? Does anyone have any RPM packages for the N900? Personally, instead of arguing back and forth, I'd like to see this made available. I like giving users choices and I'd love to see yum as a viable choice on the N900 My two cents. Aldon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo-Mailinglist Merge (MMM)
On 15/02/2010 18:42, Andre Klapper wrote: > Am Montag, den 15.02.2010, 18:25 +0100 schrieb Max: >> both mailinglists will be disabled, and merged into the megoo mailinglist >> >> Right? :-P > > No? :-P > >> When? ! > > *If* it happens: When it's time to do so. > > Maemo and Moblin both coexist right now and there is no need to pollute > each project with questions specific to the other platform respectively. > There's a Meego list at http://lists.meego.com/listinfo/meego-dev Cheers, -- Yves-Alexis ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
Am 16.02.2010 17:31, schrieb Jeremiah Foster: according to Quim http://talk.maemo.org/showthread.php?p=529073 Harmattan is going to stay DEB based, despite being the first MeeGo implementation on Nokia devices. This is IMHO good news. Now we only need to convince them to stick to it even after Harmattan... I would _love_ to see that happen. then contribute here: http://wiki.maemo.org/DebForMeeGo unfortunately I am short on time to answer in full length... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
I foresaw this was coming, the religion^W packaging war... I guess quite anybody is fed up with this kind of discussion. That would be more interesting discussing real details, for instance this is just come to my mind: How meebo will manage very different devices (for one different CPUs, architectures, screen resolutions, screen types)? It's "simple" to design a product targeting just one or few hardware devices (see maemo, Mac Os X), but it becomes really complicated when you are targeting very different hardware devices. Cheers, Luca On Tue, Feb 16, 2010 at 5:31 PM, Jeremiah Foster wrote: > > On Feb 16, 2010, at 5:27 PM, Thomas Tanner wrote: > >> On 16.02.10 17:18, Pavel Rojtberg wrote: >>> actually I only care what the MeeGo version will use that is supposed to >>> run on future Nokia handhelds. Frankly, it is suicide not to switch to rpm. >> >> you mean all .deb based distributions are doomed to fail?? > > Heavens no!! I strongly feel the opposite, that rpm distros are doomed to > fail. debs have wider adoption and have solved lots of problems already, rpms > are becoming the corporate preference, not the developer or user preference. > But for this project, MeeGo, the rpm is going to be the default format. It > seems silly if you want to get your software into MeeGo to spend too much > time arguing because I think people will not change - certainly not the Linux > Foundation who host the repos, wiki, etc. >> >>> I think I will start a wiki page and a brainstorm vote, for keeping DEBs >>> and to collect arguments pro/ contra. >> >> according to Quim http://talk.maemo.org/showthread.php?p=529073 >> Harmattan is going to stay DEB based, despite being the first MeeGo >> implementation on Nokia devices. This is IMHO good news. >> Now we only need to convince them to stick to it even after Harmattan... > > I would _love_ to see that happen. > > Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
On Feb 16, 2010, at 5:27 PM, Thomas Tanner wrote: > On 16.02.10 17:18, Pavel Rojtberg wrote: >> actually I only care what the MeeGo version will use that is supposed to >> run on future Nokia handhelds. >>> Frankly, it is suicide not to switch to rpm. > > you mean all .deb based distributions are doomed to fail?? Heavens no!! I strongly feel the opposite, that rpm distros are doomed to fail. debs have wider adoption and have solved lots of problems already, rpms are becoming the corporate preference, not the developer or user preference. But for this project, MeeGo, the rpm is going to be the default format. It seems silly if you want to get your software into MeeGo to spend too much time arguing because I think people will not change - certainly not the Linux Foundation who host the repos, wiki, etc. > >> I think I will start a wiki page and a brainstorm vote, for keeping DEBs >> and to collect arguments pro/ contra. > > according to Quim http://talk.maemo.org/showthread.php?p=529073 > Harmattan is going to stay DEB based, despite being the first MeeGo > implementation on Nokia devices. This is IMHO good news. > Now we only need to convince them to stick to it even after Harmattan... I would _love_ to see that happen. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
On 16.02.10 17:18, Pavel Rojtberg wrote: > actually I only care what the MeeGo version will use that is supposed to > run on future Nokia handhelds. >> Frankly, it is suicide not to switch to rpm. you mean all .deb based distributions are doomed to fail?? > I think I will start a wiki page and a brainstorm vote, for keeping DEBs > and to collect arguments pro/ contra. according to Quim http://talk.maemo.org/showthread.php?p=529073 Harmattan is going to stay DEB based, despite being the first MeeGo implementation on Nokia devices. This is IMHO good news. Now we only need to convince them to stick to it even after Harmattan... -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
On Feb 16, 2010, at 5:18 PM, Pavel Rojtberg wrote: > Am 16.02.2010 14:36, schrieb Jeremiah Foster: >> I highly doubt the Linux Foundation is going to go back on the Linux >> Standards Base and use .debs, but I do like your optimism. :) > actually I only care what the MeeGo version will use that is supposed to run > on future Nokia handhelds. The LSB is free to recommend whatever they want - > and as others pointed already out the standard does not say your distribution > has to be RPM based ;) No, but the LSB said you have to support installing from rpm and building rpms is the shortest path to doing that. >> I think Chrome OS is also rpm based, and I also don't think Chrome OS gets a >> lot of downloads, at least compared to Ubuntu. > Chrome OS is Ubuntu based, which is from the technical POV a very good > decision - but you can expect that from Google. Wow, cool. Didn't know that. > >> Frankly, it is suicide not to switch to rpm. > please explain that. Simply because I don't think most people care - they just want it to work. And many will just go ahead and make rpms and be done with it. Meanwhile you'll have to spend time trying to convince people not to, and this seems like a waste. You're just discussing what color to paint the bike shed, and while this is a popular pastime, it is kinda unproductive. > I used this phrase as switching to rpm means working against Google and > Canonical, which on their own have a much better expertise than either Nokia > or Intel. > > I think I will start a wiki page and a brainstorm vote, for keeping DEBs and > to collect arguments pro/ contra. Good idea. Jeremiah___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
Am 16.02.2010 14:36, schrieb Jeremiah Foster: I highly doubt the Linux Foundation is going to go back on the Linux Standards Base and use .debs, but I do like your optimism. :) actually I only care what the MeeGo version will use that is supposed to run on future Nokia handhelds. The LSB is free to recommend whatever they want - and as others pointed already out the standard does not say your distribution has to be RPM based ;) I think Chrome OS is also rpm based, and I also don't think Chrome OS gets a lot of downloads, at least compared to Ubuntu. Chrome OS is Ubuntu based, which is from the technical POV a very good decision - but you can expect that from Google. Frankly, it is suicide not to switch to rpm. please explain that. I used this phrase as switching to rpm means working against Google and Canonical, which on their own have a much better expertise than either Nokia or Intel. I think I will start a wiki page and a brainstorm vote, for keeping DEBs and to collect arguments pro/ contra. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [Hildon-Extras] New widgets: about dialog, simple color dialog
2010/2/15 Cornelius Hald : > The question is, whether or not we want that. If we release a library, we > will have to deal with API compatibility in successive versions, etc. I think it would be helpful to create/ship a library. If we don't want to create a shared library just yet, we can always create a static library + some "compatibility level" C macros to issue compiler errors when the API changes (HE_ASSUME_API_LEVEL(1)?) against which packages link against (and depend on the -dev package). Any API changes could then be documented on the webpage or the wiki, with help and code examples on how to "upgrade" to a newer API version to make it easier for developers to upgrade to a new hildon-extras API version. Of course, this means that application packages that are not updated might not build from source in the future (source packages can be easily changed to the new API version; due to the static library, binary packages will not break). Even a static library seems to be a better solution than copy'n'paste. I believe that if users of hildon-extras (developers using HE in their projects) start to copy'n'paste stuff, they might add new features and fixes only in their local version, making it a nightmare for the HE maintainers to go and "collect" all fixes from different projects and merge them into the hildon-extras repository (it's also tedious merging changes from HE to the local copy). A compiler error pointing to a Wiki page that describes how to upgrade to a newer API version seems much more developer-friendly and allows us to improve things without requiring to commit to a fixed API too early. After some months when the bugs and API annoyance are ironed out, we can create a shared library and provide API/ABI compatibility. Please point out any thought errors that I might have had here ;) Thomas ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
TreeView with variable height rows?
Hi, I'm trying to add a multi-line text to a TreeViewColumn using the "markup" property of a standard CellRendererText; The text is correctly word-wrapped so that it spans on multiple lines, but the problem is that the treeview row's height seems to be fixed - ie the text displayed is truncated horizontally and rows doesn't expand to accomodate it. Is there a way to achieve this using a standard CellRendererText or do I need to create my own CellRenderer? I'd avoid that if possible, as I don't need any fancy stuff apart from that already offered by pango markup. -- Luca Donaggio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Why touch event go through my window
Yes. I've tried that. But I still have no idea why it crashes on your device. It works well here. I'm not sure, but maybe you can try: 1. rm -rf /home/user/.scim And reboot to check if it works. 2. Reinstall it. Since someone said it works for him before: http://code.google.com/p/scim-for-maemo/issues/detail?id=22&can=1 (Comment 8) I'm trying to reproduce and fix it now. I will let you know if I have any progress on it. Thank you very much! Best regards, Evan JIANG 2010/2/16 Kimmo Hämäläinen : > On Tue, 2010-02-16 at 10:34 +0100, ext Evan JIANG wrote: >> Hi, >> Thank you for your reply. >> Which locale are you using? >> It's ok to run it under en_US on real device. The application is >> using by lots of users for 2 monthes. I think it should not have such >> problem. >> The source code can be found here: http://code.google.com/p/scim-for-maemo/ >> Well, I admit the source code is a bit complex. > > I compiled the mscim package from this Subversion trunk, but it is still > crashing after I have installed it. Have you used it in a fresh PR1.1 > N900 by just installing those two packages, nothing more? > > -Kimmo > > > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
On Tue, 16 Feb 2010, Jeremiah Foster wrote: On Feb 16, 2010, at 3:00 PM, Stuart Anderson wrote: On Tue, 16 Feb 2010, Jeremiah Foster wrote: I highly doubt the Linux Foundation is going to go back on the Linux Standards Base and use .debs, but I do like your optimism. :) Not that the LSB only specified the RPM package format. This was done because most distributions had a way of handling RPM packages (Debian uses alien). The LSB does NOT mandate that the distro itself has to use RPM, only that it be capable of correclty installing an application packaged with RPM. Debian is LSB compliant, so any other .deb based distro should be capable of doing the same. Wanting to be LSB conforming does not imply that a distro must be RPM based. Of course you are right. But be honest, do you really think these two companies are going to expend effort on supporting an apt based package manager? Do you think they are going to document using apt with rpms? Do you think they will advise new users and their own internal developers to use debs instead of rpm? Absolutely not. This is clearly a case of these 3 entities serving their own interests over those of the community. I just wanted to point out that any reasoning based on "because the LSB says so" was invalid. Stuart Stuart R. Anderson ander...@netsweng.com Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Why touch event go through my window
On Tue, 2010-02-16 at 10:34 +0100, ext Evan JIANG wrote: > Hi, > Thank you for your reply. > Which locale are you using? > It's ok to run it under en_US on real device. The application is > using by lots of users for 2 monthes. I think it should not have such > problem. > The source code can be found here: http://code.google.com/p/scim-for-maemo/ > Well, I admit the source code is a bit complex. I compiled the mscim package from this Subversion trunk, but it is still crashing after I have installed it. Have you used it in a fresh PR1.1 N900 by just installing those two packages, nothing more? -Kimmo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: RPM Vs. Deb (Was Re: MeeGo)
Fathi Boudra a écrit : That's pure speculation but it's the only rationale I found so far about the rpm choice. Quoting from a lwn.net comment: --- reference: http://www.desktoplinux.com/news/NS2068665492.html: Hohndel was quoted as saying that the move to Fedora was largely a "technical decision based on the desire to adopt RPM (Red Hat Package Manager) for package management" instead of Ubuntu's Debian DEB extension. RPM offers the advantage of containing license information, Hohndel was said to have noted, thereby enabling developers to create collections of software by license type or exclude software by license type. --- reference: http://www.phoronix.com/scan.php?page=news_item&px=Nj... "One of the examples cited by Dirk was the ability for RPMs to easily identify the license of packages and being able to build an environment including or excluding a particular license type." --- This is pointless. Debian package can contain license information if you want to. Please read the chapter "5.7 User-defined fields": http://www.debian.org/doc/debian-policy/ch-controlfields.html Adding just a "XBS-License:" line in each package control file do not justify to lose 5 years of work. Regards, Jean-Christian de Rivaz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
On Feb 16, 2010, at 3:00 PM, Stuart Anderson wrote: > On Tue, 16 Feb 2010, Jeremiah Foster wrote: >> >> I highly doubt the Linux Foundation is going to go back on the Linux >> Standards Base and use .debs, but I do like your optimism. :) > > Not that the LSB only specified the RPM package format. This was done because > most distributions had a way of handling RPM packages (Debian uses alien). > > The LSB does NOT mandate that the distro itself has to use RPM, only that it > be capable of correclty installing an application packaged with RPM. Debian > is LSB compliant, so any other .deb based distro should be capable of doing > the same. > > Wanting to be LSB conforming does not imply that a distro must be RPM based. Of course you are right. But be honest, do you really think these two companies are going to expend effort on supporting an apt based package manager? Do you think they are going to document using apt with rpms? Do you think they will advise new users and their own internal developers to use debs instead of rpm? I think bringing in a bunch of apt tools to support users who want to manage the software on their system is a worthwhile goal, and might end up improving both packaging systems, but I am a bit sanguine about "official" support for apt. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
On Tue, 16 Feb 2010, Jeremiah Foster wrote: On Feb 16, 2010, at 2:12 PM, Pavel Rojtberg wrote: Am 16.02.2010 10:16, schrieb Jeremiah Foster: Intel and Nokia do not care about the implementation of the package system, they just want revenue from app stores. The upshot from all of this is that we are stuck with RPM, there is no going back, and technical merits or even perceived technical merits do not matter. I would disagree that we are stuck with RPM. As Quim Gil posted today Harmattan will be already called MeeGo, but still use DEB. Frankly anything else would be lunatic of them from a technical POV. So I think if we as a community can create enough pressure for DEB, we can maybe keep it - there is one development cycle of time ;) I highly doubt the Linux Foundation is going to go back on the Linux Standards Base and use .debs, but I do like your optimism. :) Not that the LSB only specified the RPM package format. This was done because most distributions had a way of handling RPM packages (Debian uses alien). The LSB does NOT mandate that the distro itself has to use RPM, only that it be capable of correclty installing an application packaged with RPM. Debian is LSB compliant, so any other .deb based distro should be capable of doing the same. Wanting to be LSB conforming does not imply that a distro must be RPM based. Stuart Stuart R. Anderson ander...@netsweng.com Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RPM Vs. Deb (Was Re: MeeGo)
That's pure speculation but it's the only rationale I found so far about the rpm choice. Quoting from a lwn.net comment: --- reference: http://www.desktoplinux.com/news/NS2068665492.html: Hohndel was quoted as saying that the move to Fedora was largely a "technical decision based on the desire to adopt RPM (Red Hat Package Manager) for package management" instead of Ubuntu's Debian DEB extension. RPM offers the advantage of containing license information, Hohndel was said to have noted, thereby enabling developers to create collections of software by license type or exclude software by license type. --- reference: http://www.phoronix.com/scan.php?page=news_item&px=Nj... "One of the examples cited by Dirk was the ability for RPMs to easily identify the license of packages and being able to build an environment including or excluding a particular license type." --- Cheers, Fathi ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
On Feb 16, 2010, at 2:12 PM, Pavel Rojtberg wrote: > Am 16.02.2010 10:16, schrieb Jeremiah Foster: >> Intel and Nokia do not care about the implementation of the package system, >> they just want revenue from app stores. The upshot from all of this is that >> we are stuck with RPM, there is no going back, and technical merits or even >> perceived technical merits do not matter. > I would disagree that we are stuck with RPM. As Quim Gil posted today > Harmattan will be already called MeeGo, but still use DEB. Frankly anything > else would be lunatic of them from a technical POV. > So I think if we as a community can create enough pressure for DEB, we can > maybe keep it - there is one development cycle of time ;) I highly doubt the Linux Foundation is going to go back on the Linux Standards Base and use .debs, but I do like your optimism. :) > My point for doing so is that switching from DEB to RPM means trashing the > last 5 years of experience with this format/ the build environment, which > is a kind of a pointless rewrite. Besides there is currently a large > momentum behind it (Ubuntu, Chrome OS). Working against it is suicide ;) I think Chrome OS is also rpm based, and I also don't think Chrome OS gets a lot of downloads, at least compared to Ubuntu. Frankly, it is suicide not to switch to rpm. And I have much more to lose with the transition than you! :) Jeremiah (current maemo debmaster) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
On Tue, Feb 16, 2010 at 2:12 PM, Pavel Rojtberg wrote: > Besides there is currently a large momentum behind it (Ubuntu, Chrome OS). > Working against it is suicide ;) > > Well, in my experience Chrome OS is rather a closed platform which is not meant for installing additional packages but rather go for web-based applications. I wouldn't rely on that, nor would I bet on Android, which is barely a fully functional Linux except for the Kernel. Cheers, Chris ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
Am 16.02.2010 10:16, schrieb Jeremiah Foster: Intel and Nokia do not care about the implementation of the package system, they just want revenue from app stores. The upshot from all of this is that we are stuck with RPM, there is no going back, and technical merits or even perceived technical merits do not matter. I would disagree that we are stuck with RPM. As Quim Gil posted today Harmattan will be already called MeeGo, but still use DEB. Frankly anything else would be lunatic of them from a technical POV. So I think if we as a community can create enough pressure for DEB, we can maybe keep it - there is one development cycle of time ;) My point for doing so is that switching from DEB to RPM means trashing the last 5 years of experience with this format/ the build environment, which is a kind of a pointless rewrite. Besides there is currently a large momentum behind it (Ubuntu, Chrome OS). Working against it is suicide ;) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGarage ?
On Tue, Feb 16, 2010 at 1:08 PM, wrote: > No need for packing anything. > > The garage will stay there in place as is. It is not something that can be > just closed down. > > > > Could you post an exact link to where you see the merge info? http://meego.com/garage "Right now, we are working on merging the two garages, but it's not quite ready (there's a lot of cool stuff!) Check back soon." > > > > If the garage at some point were to merge with the MeeGo garage, that will > most definitely be discussed well in time with the community. No discussion, > no merge, as simple as that. > > > > Tero > > > > From: maemo-developers-boun...@maemo.org > [mailto:maemo-developers-boun...@maemo.org] On Behalf Of ext Attila Csipa > Sent: 15 February, 2010 22:14 > To: maemo-developers@maemo.org > Subject: MeeGarage ? > > > > The meego.com site is announcing being in the process of merging moblin and > maemo garages. As someone who has a few projects on garage.maemo.org, it > would be nice to have a few general remarks from the Maemo side of this > merger as to what the future holds, should we mentally prepare to pack our > bags, VCS', etc. > > > > Regards, > Attila > > ___ > 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: Why touch event go through my window
Because I want the window has a white board around it. If I don't set the window type hint, the window itself will be just a pure window with no board. Even set the board width doesn't work. But for sure that I've tried to remove these code to make sure the bug is not caused by these code. And I found these code is not related to the bug. Best regards, Evan JIANG 2010/2/16 Claudio Saavedra : > You first commented: > > El sáb, 06-02-2010 a las 23:53 +0800, Evan JIANG escribió: >> >> My panel is created with gtk_window_new (GTK_WINDOW_POPUP); > > And then said: > > El mar, 16-02-2010 a las 01:06 +0800, Evan JIANG escribió: >> >> gtk_window_set_type_hint (GTK_WINDOW (_input_window), >> GDK_WINDOW_TYPE_HINT_DIALOG); > > Why do you need to mess with the window types so much? Can you try > simplifying that? > > Claudio > > > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: show existing StackableWindow second time
On 16.02.2010 13:09, Martin Grimme wrote:
You need to connect to the delete-event of the subwindow and invoke
hide() in there to hide the window. Your delete callback must return
True to signalize that the windows is not to be destroyed.
Martin
Thank you!
This chunk of code works:
...
self.window.connect("delete-event", self.hide_subwindow_cb)
def hide_subwindow_cb(self, widget, event):
# redefine 'delete-event'.
# Hide window instead of it destroying
widget.emit_stop_by_name('delete-event')
widget.hide()
return True
2010/2/16, Max Usachev:
Hello!
Please, help me with hiding stackable window.
My app has Main mode and submodes.
Each submode = class instance + its UI. Each mode has Activate method:
if class instance is exists, then activate method must only show mode
UI, else, if there is no instance, method must create class instance and
its UI and show this UI. This is my code, and I can't show UI of
existing mode second time:
import gtk
import hildon
class SubMode:
def __init__(self):
self.window = None
def activate(self):
if not self.window:
self.window = hildon.StackableWindow()
self.window.set_title("SubMode")
self.window.show_all()
class TestApp():
def __init__(self):
self.window = None
self.submode_object = None
self.create_ui()
def create_ui(self):
"""Create Main mode UI."""
self.window = hildon.StackableWindow()
self.window.set_title('Main mode')
self.window.connect('destroy', gtk.main_quit)
vbox = gtk.VBox()
button = hildon.Button(gtk.HILDON_SIZE_AUTO, \
hildon.BUTTON_ARRANGEMENT_VERTICAL)
button.set_title("Activate SubMode")
button.connect('clicked', self.activate_submode)
vbox.pack_start(button)
self.window.add(vbox)
self.window.show_all()
def activate_submode(self, widget):
"""Show submode."""
if not self.submode_object:
self.submode_object = SubMode()
self.submode_object.activate()
if __name__ == "__main__":
TestApp()
gtk.main()
Br,
Max Usachev.
___
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: rpm vs. deb and "universal binaries/packages"
On Tue, 2010-02-16 at 12:17 +0100, Christopher Intemann wrote: > On Tue, Feb 16, 2010 at 11:56 AM, Andrew Flegg > wrote: > > Sure, but is there a recent i386 port of Maemo at all? :-) > No one is running Maemo on i386, not even Nokia on their Booklet 3G. Mer is - I run Mer/Maemo on the O2 Joggler which is Atom iirc. David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: MeeGarage ?
No need for packing anything. The garage will stay there in place as is. It is not something that can be just closed down. Could you post an exact link to where you see the merge info? If the garage at some point were to merge with the MeeGo garage, that will most definitely be discussed well in time with the community. No discussion, no merge, as simple as that. Tero From: maemo-developers-boun...@maemo.org [mailto:maemo-developers-boun...@maemo.org] On Behalf Of ext Attila Csipa Sent: 15 February, 2010 22:14 To: maemo-developers@maemo.org Subject: MeeGarage ? The meego.com site is announcing being in the process of merging moblin and maemo garages. As someone who has a few projects on garage.maemo.org, it would be nice to have a few general remarks from the Maemo side of this merger as to what the future holds, should we mentally prepare to pack our bags, VCS', etc. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: rpm vs. deb and "universal binaries/packages"
On Tuesday 16 February 2010 12:17:09 Christopher Intemann wrote: > common on netbooks. Of course, it is possible let the repository autodetect > the platform requesting a package and supply the matching one. On the other That is exactly how repositories in the debian world work for many years now :) > hand, Apple had a great success story when they almost seamlessly switched > from PPC to Intel by introducing their universal binaries. It's a different story. At the time of that switch, there was no central repository of software, so there was a need to make it possible for 3rd party developers to generate universal binaries and not futz with separate architectures. The concept of autobuilders and repositories makes this somewhat irrelevant - already, when you upload something to the autobuilder, it gets both ARM and X86 builds, regardless of what your original target or host machine was. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Why touch event go through my window
You first commented: El sáb, 06-02-2010 a las 23:53 +0800, Evan JIANG escribió: > > My panel is created with gtk_window_new (GTK_WINDOW_POPUP); And then said: El mar, 16-02-2010 a las 01:06 +0800, Evan JIANG escribió: > > gtk_window_set_type_hint (GTK_WINDOW (_input_window), > GDK_WINDOW_TYPE_HINT_DIALOG); Why do you need to mess with the window types so much? Can you try simplifying that? Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: rpm vs. deb and "universal binaries/packages"
On Tue, Feb 16, 2010 at 12:17 PM, Christopher Intemann wrote: [...] > Apple had a great success story when they almost seamlessly switched > from PPC to Intel by introducing their universal binaries. That wouldn't work too well for ARM: you'd want ARMv6 with or without VFP, ARMv7-A with or without VFP + with or without NEON (and also with a poor VFP so that you should use NEON). Of course one can always hope dev's would select at runtime the fastest function for the platform, but that's only hope :-) Laurent ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: rpm vs. deb and "universal binaries/packages"
On Tue, Feb 16, 2010 at 11:17, Christopher Intemann wrote: > On Tue, Feb 16, 2010 at 11:56 AM, Andrew Flegg wrote: >> On Tue, Feb 16, 2010 at 10:46, Christopher Intemann >> wrote: >> >> > Of course, this would probably double the size of the rpm/deb, [...] >> >> ...and so the download. > > Yes, that's true, but since we're talking about mobile devices with > limited hardware, the apps are usually not that big anyways. I was just > thinking that the benefit would outbalance the size issue, at least as > long as we're talking about download sizes of one or two megabyte. Qt 4.6 and Python are *both* above the 30MB mark. > Sure, but is there a recent i386 port of Maemo at all? :-) Err, anyone who uses Scratchbox and develops on their PC rather than the device is running i386 Maemo. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: rpm vs. deb and "universal binaries/packages"
On Tue, Feb 16, 2010 at 11:56 AM, Andrew Flegg wrote: > On Tue, Feb 16, 2010 at 10:46, Christopher Intemann > wrote: > > Since MeeGo is about to be released as well for the ARM as the Intel > > platform, I really wonder whether either of the package formats (rpm/deb) > > has the capability to include both binaries (ARM and Intel) but install > > only the matching one automatically? > > Why not leave it up to the builder? Our current auto-builder, and OBS > (as used by Moblin & MeeGo) both support the building of multiple > architectures into multiple repositories. > > > Of course, this would probably double the size of the rpm/deb, [...] > > ...and so the download. > > Yes, that's true, but since we're talking about mobile devices with limited hardware, the apps are usually not that big anyways. I was just thinking that the benefit would outbalance the size issue, at least as long as we're talking about download sizes of one or two megabyte. > > It would then be more transparent for the enduser to install additional > > packages without having to think of their hardware architecture... > > Surely the user is going to be getting the package through some kind > of package manager which makes the distinction moot? How often have > you had to decide between i386 or armel debs on your Maemo device to > date? > > Sure, but is there a recent i386 port of Maemo at all? :-) No one is running Maemo on i386, not even Nokia on their Booklet 3G. However, this is likely to change in the future, since Moblin is already common on netbooks. Of course, it is possible let the repository autodetect the platform requesting a package and supply the matching one. On the other hand, Apple had a great success story when they almost seamlessly switched from PPC to Intel by introducing their universal binaries. I'm just curious: Does either rpm or deb provide this feature? Chris ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: show existing StackableWindow second time
You need to connect to the delete-event of the subwindow and invoke
hide() in there to hide the window. Your delete callback must return
True to signalize that the windows is not to be destroyed.
Martin
2010/2/16, Max Usachev :
> Hello!
> Please, help me with hiding stackable window.
> My app has Main mode and submodes.
> Each submode = class instance + its UI. Each mode has Activate method:
> if class instance is exists, then activate method must only show mode
> UI, else, if there is no instance, method must create class instance and
> its UI and show this UI. This is my code, and I can't show UI of
> existing mode second time:
>
> import gtk
> import hildon
>
> class SubMode:
> def __init__(self):
> self.window = None
>
> def activate(self):
> if not self.window:
> self.window = hildon.StackableWindow()
> self.window.set_title("SubMode")
> self.window.show_all()
>
> class TestApp():
> def __init__(self):
> self.window = None
> self.submode_object = None
> self.create_ui()
>
> def create_ui(self):
> """Create Main mode UI."""
> self.window = hildon.StackableWindow()
> self.window.set_title('Main mode')
> self.window.connect('destroy', gtk.main_quit)
> vbox = gtk.VBox()
> button = hildon.Button(gtk.HILDON_SIZE_AUTO, \
> hildon.BUTTON_ARRANGEMENT_VERTICAL)
> button.set_title("Activate SubMode")
> button.connect('clicked', self.activate_submode)
> vbox.pack_start(button)
> self.window.add(vbox)
> self.window.show_all()
>
> def activate_submode(self, widget):
> """Show submode."""
> if not self.submode_object:
> self.submode_object = SubMode()
> self.submode_object.activate()
>
>
> if __name__ == "__main__":
> TestApp()
> gtk.main()
>
>
>
> Br,
> Max Usachev.
> ___
> 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: rpm vs. deb and "universal binaries/packages"
On Tue, Feb 16, 2010 at 10:46, Christopher Intemann wrote: > Since MeeGo is about to be released as well for the ARM as the Intel > platform, I really wonder whether either of the package formats (rpm/deb) > has the capability to include both binaries (ARM and Intel) but install > only the matching one automatically? Why not leave it up to the builder? Our current auto-builder, and OBS (as used by Moblin & MeeGo) both support the building of multiple architectures into multiple repositories. > Of course, this would probably double the size of the rpm/deb, [...] ...and so the download. > It would then be more transparent for the enduser to install additional > packages without having to think of their hardware architecture... Surely the user is going to be getting the package through some kind of package manager which makes the distinction moot? How often have you had to decide between i386 or armel debs on your Maemo device to date? Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
En/na Jeremiah Foster ha escrit: The APT system as a whole is better than RPM. Apples and oranges. You can compare apt to urpmi or dpkg to rpm. You can't compare apt to rpm. For me urpmi is slightly better than apt, but that's just a personal opinion based on my usage pattern and experience. On the whole I'd say they're quite similar, neither is vastly better than the other. Bye -- Luca ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
rpm vs. deb and "universal binaries/packages"
Since MeeGo is about to be released as well for the ARM as the Intel platform, I really wonder whether either of the package formats (rpm/deb) has the capability to include both binaries (ARM and Intel) but install only the matching one automatically? Of course, this would probably double the size of the rpm/deb, but would not affect the size after install. It would then be more transparent for the enduser to install additional packages without having to think of their hardware architecture... Chris ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Why touch event go through my window
On Tue, 2010-02-16 at 10:34 +0100, ext Evan JIANG wrote: > Hi, > Thank you for your reply. > Which locale are you using? > It's ok to run it under en_US on real device. The application is > using by lots of users for 2 monthes. I think it should not have such > problem. > The source code can be found here: http://code.google.com/p/scim-for-maemo/ > Well, I admit the source code is a bit complex. I had "fi_FI". I tried with "en_US" but it crashes with that also... I think it should not crash whatever the locale is, don't you agree? -Kimmo > > Best regards, > Evan JIANG > > 2010/2/16 Kimmo Hämäläinen : > > On Mon, 2010-02-15 at 18:06 +0100, ext Evan JIANG wrote: > >> Hi, > > ... > >> The application is in mameo extras-devel repository. Could you help me > >> to test that? > >> You can get it from > >> http://repository.maemo.org/extras-devel/pool/fremantle/free/m/mscim/mscim_1.4.7-1maemo5_armel.deb > >> It's not the latest version in the repository. Because I've applied my > >> workaround since > >> mscim_1.4.7-1maemo6_armel, you need to try one before version > >> 1.4.7-1maemo6. > >> And please also install mscim-googlepinyin package from maemo > >> extras-devel repository. The input method only works after both of > >> these 2 packages are installed. > > > > I installed mscim-googlepinyin 0.11.10-1maemo3 and mscim 1.4.7-1maemo5 > > but it is not working. scim-panel-gtk is crashing with signal 6. I > > attached the syslog with one message. > > > > I tried with our latest Maemo5 version and with 51-1 image but the same > > thing happens in both. > > > > How to get it to run? > > > > -Kimmo > > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo, unity or fragmentation?
On 16.02.2010 08:25, Marcin Juszkiewicz wrote: > On pon 15 lut 2010 21:49:14 CET, Pavel Rojtberg wrote: > >>> I guess the first MeeGo release will be >>> widely based on Maemo but use rpm as packaging format. > > Maemo maybe is longer on a market but will rather not be a base - will rather > provide applications and phone stuff. > >> In general I think the package format needs more discussion as it also >> implies a rebase of the distribution. > > There is no space for discussion - we are community not company. Moblin > already has OBS working for building software and they decided about using > Fedora as base over 18 months ago (used Ubuntu before). The more precise way would be to say that moblin "is based on the RPM format (used also by Fedora)" than "using Fedora as a base". Check out the FAQ: http://moblin.org/documentation/moblin-overview/faq >> Up to now Maemo was happily >> syncing from Debian, which obviously wont work with rpm any more. > > Please... Maemo was not syncing with Debian. It just took few updated > components from it. So it is exactly like in Moblin+Debian/Fedora case... >> So there must be at least a HUGE advantage coming with RPM to justify >> the efford to switch. > > Less work for nokia on base system as Moblin provides nice working, > maintained one instead of bunch of random versions used in Maemo5. There you can read about some reasons (like "the ability to track the license of a package as part of the spec file"): http://iquaid.org/2008/07/25/a-word-about-intels-moblin-and-fedora/ Regards, miko ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo, unity or fragmentation?
On 16.02.2010 08:25, Marcin Juszkiewicz wrote: > On pon 15 lut 2010 21:49:14 CET, Pavel Rojtberg wrote: > >>> I guess the first MeeGo release will be >>> widely based on Maemo but use rpm as packaging format. > > Maemo maybe is longer on a market but will rather not be a base - will rather > provide applications and phone stuff. > >> In general I think the package format needs more discussion as it also >> implies a rebase of the distribution. > > There is no space for discussion - we are community not company. Moblin > already has OBS working for building software and they decided about using > Fedora as base over 18 months ago (used Ubuntu before). The more precise way would be to say that moblin "is based on the RPM format (used also by Fedora)" than "using Fedora as a base". Check out the FAQ: http://moblin.org/documentation/moblin-overview/faq >> Up to now Maemo was happily >> syncing from Debian, which obviously wont work with rpm any more. > > Please... Maemo was not syncing with Debian. It just took few updated > components from it. So it is exactly like in Moblin+Debian/Fedora case... >> So there must be at least a HUGE advantage coming with RPM to justify >> the efford to switch. > > Less work for nokia on base system as Moblin provides nice working, > maintained one instead of bunch of random versions used in Maemo5. There you can read about some reasons (like "the ability to track the license of a package as part of the spec file"): http://iquaid.org/2008/07/25/a-word-about-intels-moblin-and-fedora/ Regards, miko ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
Kees Jongenburger a écrit : On Tue, Feb 16, 2010 at 9:59 AM, Jean-Christian de Rivaz wrote: Aside of this, I am puzzled to see a project that it targeted to support both X86 and ARM processors without even considering the multiarch future. Sound crasy to me. Debian have accumulated a immense amount of knowledge on how to do this the right way and there have made many changes in the package management to handle multiarch. RPM packaging is completely outdated about this. Hi, Debian does handle "multiarch" ok in repositories and such but wake up and look around it is not special or anything. Debian is far far behind when is comes to "multiarch" and real device support. They only provide unoptimized generic armv5 code http://www.debian.org/ports/arm/ and the way debian works (no cross compiling) makes it a pain to port to other platforms. You have to see not only the current state but also the goal. Only Debian will be ready for multiarch is a foreseeable future. Others distributions have just missed the point that all the current way to build embedded system will be obsolet soon. In the near future, there will be no difference between your PC and you phone from the distribution point of view. So a SDK for embedded system will be pointless. Even the word "embedded" will be dropped. It's perfectly doable to start a new armv7 port into Debian if it make sense to do it. now try and compare that to something like poky http://www.pokylinux.org/ I work with SB2, OE, Buildroot and LTIB. For me there are all already something of the past. Regards, Jean-Christian de Rivaz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
On 16.02.2010 08:44, Martin Grimme wrote: > I think this is the real problem about rpm here. Technically, I think > rpm is superior to deb but Debian's apt is still unmatched as a > package manager and the packagers do a better job (maybe because deb > is easier to create?). I haven't used yum for years, so it might be > better today, but back then (2004/2005), badly packaged stuff with bad > dependencies and the utter slowness of yum drove me away from Redhat. Mee too ;( BTW, I am using archlinux now and its pacman package manager - it it simply beatiful compared to rpm/deb - you can create new packages usually in "no-time". For me, both deb and rpm are "poisoned" by using macros: they have similar names but different implementations across linux distributions, or they are present in one distro and not in the other, and this is the worst problem of RPM (and also deb, I suspect). I was creating deb and rpm packages long time ago, but now knowing pacman and the current state of deb/rpm packages, it is really hard to go back :( > I was involved in a project creating a Linux LiveCD builder based on > Fedora for customer-customisable CDs. The user selects the > applications she wants on the CD and the CD builder automatically > resolves the package dependencies to build the CD. While in theory This is what "just works" with pacman - see http://larch.berlios.de/doc/larch_overview.html I know the rpm path is already decided, just wanted to point at an alternative simpler solution which just works. Regards, miko ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Why touch event go through my window
Hi, Thank you for your reply. Which locale are you using? It's ok to run it under en_US on real device. The application is using by lots of users for 2 monthes. I think it should not have such problem. The source code can be found here: http://code.google.com/p/scim-for-maemo/ Well, I admit the source code is a bit complex. Best regards, Evan JIANG 2010/2/16 Kimmo Hämäläinen : > On Mon, 2010-02-15 at 18:06 +0100, ext Evan JIANG wrote: >> Hi, > ... >> The application is in mameo extras-devel repository. Could you help me >> to test that? >> You can get it from >> http://repository.maemo.org/extras-devel/pool/fremantle/free/m/mscim/mscim_1.4.7-1maemo5_armel.deb >> It's not the latest version in the repository. Because I've applied my >> workaround since >> mscim_1.4.7-1maemo6_armel, you need to try one before version 1.4.7-1maemo6. >> And please also install mscim-googlepinyin package from maemo >> extras-devel repository. The input method only works after both of >> these 2 packages are installed. > > I installed mscim-googlepinyin 0.11.10-1maemo3 and mscim 1.4.7-1maemo5 > but it is not working. scim-panel-gtk is crashing with signal 6. I > attached the syslog with one message. > > I tried with our latest Maemo5 version and with 51-1 image but the same > thing happens in both. > > How to get it to run? > > -Kimmo > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
On 16/02/2010 10:15, Kees Jongenburger wrote: > Hi, Debian does handle "multiarch" ok in repositories and such but > wake up and look around it is not special or anything. Debian is far > far behind when is comes to "multiarch" and real device support. Multi-arch is supposed to be implemented for Squeeze (next release) and the work as started, though some stuff is not yet decided (I can't really say much more as it's not an easy situation and I don't know enough about that) They > only provide unoptimized generic armv5 code > http://www.debian.org/ports/arm/ and the way debian works (no cross > compiling) makes it a pain to port to other platforms. That has not much to do with multi-arch though. Cross compilation is nice but it's not exactly required. Sure the infrastructure could be nicer to system on chip, but it's basically a *pain* to be generic enough if you still want to provide packages usable for everyone and still be able to use recent features. Cheers, -- Yves-Alexis ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
On Feb 16, 2010, at 9:59 AM, Jean-Christian de Rivaz wrote: > Yves-Alexis Perez a écrit : > > Absolutely right. The success of Ubuntu and Debian have proved this. > > Aside of this, I am puzzled to see a project that it targeted to > support both X86 and ARM processors without even considering the > multiarch future. Sound crasy to me. Debian have accumulated a > immense amount of knowledge on how to do this the right way and > there have made many changes in the package management to handle > multiarch. RPM packaging is completely outdated about this. What is at issue is developers. Intel and Maemo want to merge their projects to gain an economy of scale. Both Intel and Nokia know that they have to have a neutral third party to manage the project, otherwise devs will feel it is 'owned' by Nokia or Intel. So they turned to the Linux Foundation to host repos and such. The Linux Foundation is also deeply involved in the Linux Standards Base which decided that to be compliant with the LSB you have to support RPM. http://en.wikipedia.org/wiki/Linux_Standard_Base#Choice_of_RPM_package_format The APT system as a whole is better than RPM. One might argue that this has been proven by the runaway success of Ubuntu and other deb based distros, like Linux Mint. The wide adoption would certainly indicate that it is more user friendly especially since debian has never marketed its system nor locked in users, as Red Hat has. (Remember Red Hat's move to paid support?) Intel and Nokia do not care about the implementation of the package system, they just want revenue from app stores. The upshot from all of this is that we are stuck with RPM, there is no going back, and technical merits or even perceived technical merits do not matter. Fortunately RPM is not that hideous, at least for most use cases, and there are lots of tools like alien to convert from RPM to APT. If you as a developer are unwilling to work for these large companies, you may want to seriously consider Mer - a Maemo-based distribution designed to run on embedded devices which is much more open than MeeGo and uses APT. Jeremiah___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
On Tue, Feb 16, 2010 at 9:59 AM, Jean-Christian de Rivaz wrote: > Aside of this, I am puzzled to see a project that it targeted to > support both X86 and ARM processors without even considering the > multiarch future. Sound crasy to me. Debian have accumulated a > immense amount of knowledge on how to do this the right way and > there have made many changes in the package management to handle > multiarch. RPM packaging is completely outdated about this. Hi, Debian does handle "multiarch" ok in repositories and such but wake up and look around it is not special or anything. Debian is far far behind when is comes to "multiarch" and real device support. They only provide unoptimized generic armv5 code http://www.debian.org/ports/arm/ and the way debian works (no cross compiling) makes it a pain to port to other platforms. now try and compare that to something like poky http://www.pokylinux.org/ Kind regards > > Regards, > > Jean-Christian de Rivaz > ___ > 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: RPM vs. Deb (was Re: MeeGo)
On 15/02/2010 19:07, Michael Cronenworth wrote: > Thomas, you're getting all upset over nothing. The fact that RPM will > now be used is nothing more than politics. I disagree. Well, if RPM was chosen because of politics, I think it's a bad decision. If it was chosen because of technical reasons, it'd have been nice to know them. My guess is just that it's a compromise (something like “we take QT from Maemo if we take RPM from Moblin”). One *technical* reason might be that RPM is part of LSB, though I'm not sure it's really a good one. > No features will be lost. I do hope so. RPM and DEB formats *are* different and don't achieve the same goals. RPM is able to do quite a lot of stuff (think file-dependencies for example) which DEB can't do (for good reasons), the opposite is true too. And, like other said, that's not only about the format and the packaging itself, but the whole infrastructure. Cheers, -- Yves-Alexis ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
Yves-Alexis Perez a écrit : On 15/02/2010 17:29, Luca De Cicco wrote: I would stay away of packaging holy wars (packaging is boooring) :). It is true that packaging has some technical implications, however I would focus more on the scenario we are going to experience. But packaging is a whole part of a good user experience. Bad packaging means *bad* user experience, trust me. Absolutely right. The success of Ubuntu and Debian have proved this. Aside of this, I am puzzled to see a project that it targeted to support both X86 and ARM processors without even considering the multiarch future. Sound crasy to me. Debian have accumulated a immense amount of knowledge on how to do this the right way and there have made many changes in the package management to handle multiarch. RPM packaging is completely outdated about this. Regards, Jean-Christian de Rivaz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Why touch event go through my window
On Mon, 2010-02-15 at 18:06 +0100, ext Evan JIANG wrote: > Hi, ... > The application is in mameo extras-devel repository. Could you help me > to test that? > You can get it from > http://repository.maemo.org/extras-devel/pool/fremantle/free/m/mscim/mscim_1.4.7-1maemo5_armel.deb > It's not the latest version in the repository. Because I've applied my > workaround since > mscim_1.4.7-1maemo6_armel, you need to try one before version 1.4.7-1maemo6. > And please also install mscim-googlepinyin package from maemo > extras-devel repository. The input method only works after both of > these 2 packages are installed. I installed mscim-googlepinyin 0.11.10-1maemo3 and mscim 1.4.7-1maemo5 but it is not working. scim-panel-gtk is crashing with signal 6. I attached the syslog with one message. I tried with our latest Maemo5 version and with 51-1 image but the same thing happens in both. How to get it to run? -Kimmo Feb 16 10:39:47 Nokia-N900-51-1 scim-panel-gtk[1558]: GLIB WARNING ** Gtk - Locale not supported by C library. ^IUsing the fallback 'C' locale. Failed to initialize Panel Agent! Feb 16 10:39:51 Nokia-N900-51-1 crash_reporter_daemon[1294]: [creporter_get_rcore_fileinfo]: File: /home/user/MyDocs/core-dumps/scim-panel-gtk-6BF7-6-1463.rcore.lzo size 624089 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
show existing StackableWindow second time
Hello!
Please, help me with hiding stackable window.
My app has Main mode and submodes.
Each submode = class instance + its UI. Each mode has Activate method:
if class instance is exists, then activate method must only show mode
UI, else, if there is no instance, method must create class instance and
its UI and show this UI. This is my code, and I can't show UI of
existing mode second time:
import gtk
import hildon
class SubMode:
def __init__(self):
self.window = None
def activate(self):
if not self.window:
self.window = hildon.StackableWindow()
self.window.set_title("SubMode")
self.window.show_all()
class TestApp():
def __init__(self):
self.window = None
self.submode_object = None
self.create_ui()
def create_ui(self):
"""Create Main mode UI."""
self.window = hildon.StackableWindow()
self.window.set_title('Main mode')
self.window.connect('destroy', gtk.main_quit)
vbox = gtk.VBox()
button = hildon.Button(gtk.HILDON_SIZE_AUTO, \
hildon.BUTTON_ARRANGEMENT_VERTICAL)
button.set_title("Activate SubMode")
button.connect('clicked', self.activate_submode)
vbox.pack_start(button)
self.window.add(vbox)
self.window.show_all()
def activate_submode(self, widget):
"""Show submode."""
if not self.submode_object:
self.submode_object = SubMode()
self.submode_object.activate()
if __name__ == "__main__":
TestApp()
gtk.main()
Br,
Max Usachev.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
