Re: How to block the camera app from starting on lens cover open
On ven., 2010-07-23 at 19:20 +0300, Martin Storsjö wrote: > Any hints on how to solve this in the best way? I don't want my app to > fail in the next QA round with the reason "camera app is launched and > closes immediately if the lens cover is opened while your app is running". Did you check how fcamera is doing it? Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to resolve network connectivity without using Qt Mobility in Qt?
On 22/07/2010 10:59, Marius Vollmer wrote: > ext Yves-Alexis Perez writes: (no need to CC: me, I'm subcribed) >> On 22/07/2010 10:10, Marius Vollmer wrote: >>> The Application Manager has been 'optimized' for repositories, and the >>> code for dealing with Debian package files has been neglected. Now with >>> the Ovi Store using standalone Debian packages, we should finally fix >>> that. >> >> Again, wouldn't it be easier and smarter (at least technically) to fix >> ovi store? > > Don't know. We are doing this for Harmattan, and it isn't really that > easy or fast... > >> What's the point of (basically) running dpkg -i instead of apt-get >> install? > > If you use apt-get unmodified, you need to provide permanent download > URLs for the packages, and my understanding is that the Ovi Store can > not provide those _and_ control their accesses. They protect against > unauthorized downloads by using random, temporary URLs. That looks over-engineered. Using authenticated https to download packages should work and fix the various problem using reliable (well, considering TLS is reliable) ways. Not sure how much the libapt version in Fremantle supports https, but... > > Another issue is scalability: we don't want to download the meta data > for the whole Ovi Store during apt-get update. Well, at least that would mean we could browse Ovi Store from HAM, not the browser, which is more consistent for user experience, imho. Did you try pdiffs support, too? -- Yves-Alexis ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to resolve network connectivity without using Qt Mobility in Qt?
On 22/07/2010 10:24, Daniil Ivanov wrote: > Hi Yves-Alexis! (please don't CC: me, I'm subscribed) > >The point is security as these are paid applications. > This is not “security” anyway. And I fail to see how this can help paid applications, but as we don't really have details on Ovi store infrastructure, I guess I lack some information. Anyway, I'm pretty sure there are better ways to do that without “abusing” HAM. Cheers, -- Yves-Alexis ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to resolve network connectivity without using Qt Mobility in Qt?
On 22/07/2010 10:10, Marius Vollmer wrote: > The Application Manager has been 'optimized' for repositories, and the > code for dealing with Debian package files has been neglected. Now with > the Ovi Store using standalone Debian packages, we should finally fix > that. Again, wouldn't it be easier and smarter (at least technically) to fix ovi store? What's the point of (basically) running dpkg -i instead of apt-get install? Cheers, -- Yves-Alexis ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to to manually package Qt Mobility?
On 21/07/2010 09:08, Sascha Mäkelä wrote: > Hi Taneli, > > And how is that done? I have no experience in such things. Could you > perhaps point me to some How-To pages? Imho the best solution would be to fix Ovi store, but... -- Yves-Alexis ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Methods for developping on the device itself
On 08/07/2010 11:10, Piñeiro wrote: > I know that this is offtopic but, just to fulfill my curiosity. Why do > you want to compile on the device itself instead of compile it in a > scratchbox on your normal PC ? > Maybe because scratchbox is a pain? -- Yves-Alexis ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Low Latency Audio Capture on the N900, QAudioInput BUG: has 5000msec latency, Meego audio future
On mer., 2010-06-16 at 13:15 +0300, Sivan Greenberg wrote: > > I think you are barking at the wrong tree - pulseaudio should get way > > better latency than 5000ms, otherwise it would be useless for pretty > > much everything. > > My thought exactly. If that really is the case, a proper phone > conversation would had never been possible on the device, but my > everyday shows it is :-) > Not wanting to put oil on the fire (or so we say), but he said that QAudioInput bug had 5000ms latency, not pulseaudio, and afaik Maemo 5 uses gstreamer, so I guess no QAudioInput there. -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT Packages, Repositories and PR1.2
On 21/05/2010 09:34, Ville M. Vainio wrote: > No, it means PR1.2 will probably happen sooner than you think. And we've never been so close to the release! -- Yves-Alexis ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Keeping backlight on
On 11/05/2010 12:54, David Weinehall wrote: > An (undocumented) alternative is: > > gconftool -s --type int /system/osso/dsm/display/inhibit_blank_mode 3 > > Replace the 3 for whatever inhibit mode you want: > > 0 -- No display blanking inhibit > 1 -- Inhibit dimming/blanking if charger is connected > 2 -- Allow dimming, but inhibit blanking if charger is connected > 3 -- Inhibit dimming/blanking > 4 -- Allow dimming, but inhibit blanking And that'll change the user setting, which might not be a good idea from an application developer pov. Cheers, -- Yves-Alexis ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: reliability of hal-device battery data?
On jeu., 2010-02-18 at 09:59 +0100, Laurent GUERBY wrote: > After staying constant at 51% in one minute the charge level went from > 53 to 95 when I just unpluged and then repluged the charger. > > Is there a software way to force the N900 to reevaluate the current > battery level? Afaik the battery level is not reliable when charging. So no, unless you unplug the charger and let it settle down. Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
On mer., 2010-02-17 at 22:49 +, Carlos Morgado wrote: > Honestly, I'll won't even bother with MeeGo 'till I see products and a > decent roadmap. Meanwhile Nokia must just change it's mind, buy some GUI > toolkit in Java and decide that's the way to go, go back to Symbian or just > fold. Nobody knows. You might have missed the part where the first Meego phone won't be a Nokia. Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ 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
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: 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, unity or fragmentation?
On 15/02/2010 22:26, Christopher Intemann wrote: > Well, I'm using Fedora on my desktop, so rpm is just fine for me... > There seems to be an Fedora/ARM port available: > http://fedoraproject.org/wiki/Architectures/ARM > However, since I'm not very familiar with that architecture, I can't say > anything about the status compared to Debian/ARM. That's not really the point. Maemo 5 uses (outdated) sources from Debian Etch, but they are rebuilt anyway (debian armel is built for armv4t to retain compatibility, dropping speed improvements from armv7) I have, however, > always had the impression, that Fedora/RedHat/SuSE (the rpm-based > distros) were rather targeting business users, while Debian was ment for > personal users or kernel hackers in the first line. Imho that's just an impression, because Suse/Redhat are commercial players and you use RHEL/SLES with support. And, I wasn't very > amused when I had to compile several security updates and do the patches > on some Debian boxes by myself when those Debian maintainers were having > arguments and were not updating the repositories some time ago. What exactly are you talking about? (though it's not the correct place to troll distro, we were talking packaging format). In other news, I'm still not sure how those “security updates” are handled in maemo (they seem not be). Don't know at all for Moblin. However, > I'm aware that the Debian community is probably the biggest contributor > to Linux. You're right, even if it does not bother me very much, Maemo > merging into MeeGo implies a change from Debian to Fedora, if you want > to say it that way. This will probably a big loss for the Debian/ARM > project. Like I said above, Maemo doesn't use directly Debian armel. They do use Debian package but with huge modifications and rebuilt. By the way: Which, if at all, package management does Android use? Jar stuff, I guess. Cheers, -- Yves-Alexis signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
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. Cheers, -- Yves-Alexis signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 6 Security questions
On sam., 2010-02-13 at 08:46 +0100, Kees Jongenburger wrote: > In normal more: > Will I be able to gain root access? > Will I be able to debug/strace programs on the device? > Will the end user be involved in the credentials a package gets ? > (Can I accept lower security for my own programs or change the > policy?) > Will the contact data be protected by the security framework and will > I be able to export it? > Will I be able to probe kernel modules or use /dev/mem /dev/kmem? > what kind of protection are there against runtime attacks(buffer > overflows etc)? > > In "no drm mode" > Will I be able to make phone calls? > Will I be able to access the phonebook etc? > Will binaries refuse to start because they get started in this mode or > crash because they don't get what they want? > Will all normal devices function (batter charging,wifi. phone functionality)? You might want to look at http://wiki.maemo.org/Maemo_security and http://wiki.maemo.org/Talk:Maemo_security and maybe edit to ask more question. Elena Reshetova has been editing it at some point so she might answer (not sure if she's reading maemo-developers though). There's a thread about that too at http://talk.maemo.org/showthread.php?t=32672 Cheers, -- Yves-Alexis -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Is the N900 running X-Windows?! (was: Maemo 5 and hw accelerated X.Org?)
On jeu., 2010-02-11 at 00:01 +0300, 白い熊 wrote: > What am I doing wrong? Maybe check DISPLAY environment variable. -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [New Developer]: Questions - Python Packaging / Free or Non-Free / Software Licensing
On 07/02/2010 20:04, igor.sto...@nokia.com wrote: > However it's not impossible to do secure operations on the N900, they > just must be done on the cellular modem, which is perfectly capable > to manage keys in a way that is not worse than any other Nokia > phone. And afaik the omap3 supports Trustzone, so it should even be possible to use it even before Maemo6 comes, though it might be a bit tricky without OS support. Cheers, -- Yves-Alexis signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Getting a CC: for cauldon mails (extras-devel)
On 07/02/2010 11:24, Ed Bartosh wrote: > 2010/2/7 Yves-Alexis Perez : >> On 07/02/2010 01:30, Ed Bartosh wrote: >>> 2010/2/7 Yves-Alexis Perez : >>>> On 06/02/2010 22:11, Ed Bartosh wrote: >>>>> As far as I remember autobuilder doesn't use 'Maintainer' or any other >>>>> field to prevent spamming of innocent people from upstream projects. >>>>> It uses email from /etc/passed instead. Your email should be put in >>>>> there by admins when they gave you upload rights. >>>>> >>>> My garage account is 'corsac'. The associated mail should be >>>> cor...@debian.org or maybe cor...@corsac.net. >>>> >>> Unfortunately there is no email specified for your username in >>> /etc/passwd§. And not only for you, but for dozens of other uploaders >>> also. Looks like it's time to go to bugs.maemo.org. >>> >> Do you want me to do that or do you take care of that? >> > It would be better if you do this. > I can ask admins to look at this, but having a bug will help also. > Thanks, the bug is https://bugs.maemo.org/show_bug.cgi?id=8886 Cheers, -- Yves-Alexis signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Getting a CC: for cauldon mails (extras-devel)
On 07/02/2010 01:30, Ed Bartosh wrote: > 2010/2/7 Yves-Alexis Perez : >> On 06/02/2010 22:11, Ed Bartosh wrote: >>> As far as I remember autobuilder doesn't use 'Maintainer' or any other >>> field to prevent spamming of innocent people from upstream projects. >>> It uses email from /etc/passed instead. Your email should be put in >>> there by admins when they gave you upload rights. >>> >> My garage account is 'corsac'. The associated mail should be >> cor...@debian.org or maybe cor...@corsac.net. >> > Unfortunately there is no email specified for your username in > /etc/passwd§. And not only for you, but for dozens of other uploaders > also. Looks like it's time to go to bugs.maemo.org. > Do you want me to do that or do you take care of that? Cheers, -- Yves-Alexis signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Getting a CC: for cauldon mails (extras-devel)
On 06/02/2010 22:11, Ed Bartosh wrote: > As far as I remember autobuilder doesn't use 'Maintainer' or any other > field to prevent spamming of innocent people from upstream projects. > It uses email from /etc/passed instead. Your email should be put in > there by admins when they gave you upload rights. > My garage account is 'corsac'. The associated mail should be cor...@debian.org or maybe cor...@corsac.net. Cheers, -- Yves-Alexis signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Getting a CC: for cauldon mails (extras-devel)
On 06/02/2010 20:47, Attila Csipa wrote: > Already is that way, but doublecheck that you actually have the correct email > address in the Maintainer: field, one, to get the build result email, and > two, > not to pester somebody upstream who is apparently getting the build error > mails instead :) Mhmh, sorry to bother then. But no, I set the correct Maintainer: and didn't receive anything. I'll check my spam stuff, too, but it puzzles me a little. Cheers, -- Yves-Alexis signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Getting a CC: for cauldon mails (extras-devel)
Hey, I just uploaded my first package to extras-devel, which was rejected (for valid reason), but I had to dig the cauldron list archive to get that mail. I don't really want to subscribe to that list, I'm already subsribed to debian-devel-changes and it's too noisy for apps I'm not interested in :) So it'd be nice to have a CC: when the package is accepted/rejected. In Debian, this is done by checking the signature on the .changes file, but as the upload aren't signed it's not really possible here. But changed-by might be used, or maybe use garage (since we use the garage account and the ssh key associated). What do you think? -- Yves-Alexis signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Query (Maemo) packages
On 05/02/2010 16:36, Timo Härkönen wrote: > You could try Forum Nokia's remote device access service. > > http://www.forum.nokia.com/Technology_Topics/Application_Quality/Testing/Remote_Device_Access/ Remote Device Access (RDA) is a service that allows developers to test their mobile applications and services remotely on various Nokia devices based on Symbian OS -- Yves-Alexis ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo code in Linux kernel?
On 04/02/2010 12:32, Jeff Moe wrote: > At least for the N900 the answer is "no". The touchscreen driver disappeared > at 2.6.29: > drivers/input/touchscreen/tsc2005.c > I didn't found tsc2005.c in 2.6.28: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/input/touchscreen;h=cc73814e591a07b26f4214a582aeea654a519baf;hb=4a6908a3a050aacc9c3a2f36b276b46c0629ad91 Was tsc2005.c really accepted upstream at one point? Cheers, -- Yves-Alexis ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo code in Linux kernel?
On 04/02/2010 13:13, Rémi Denis-Courmont wrote: > I am surely missing some pieces. Not that some of the N900-related > contributions were merged upstream after the 2.6.28 kernel. > Obviously, there are also some parts which haven't been merged, or not yet. I wanted to ask a question about the already upstreamed stuff. Is it maintained in the linus tree? I mean, I guess the development is made in Nokia tree (which is not public, sadly), but once the first upstreaming is done, are the updates pushed regularly or is the stuff maintained only privately (which then makes it harder to follow upstream development). Cheers, -- Yves-Alexis ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo Base Port documentation
On 04/02/2010 11:56, Quim Gil wrote: > We don't expect to find many chipset vendors in this list, but still > this new doc might be interesting for those of you interested in the low > level interfaces of the platform and also for those with an open source > agenda. What exactly does 'chipset vendors' mean? The documents seems to indicates what the *sofware* (the 'base layer') should provide to be called Maemo (and be able to run the middleware and applications on top of it, so I guess it targets other hardware (complete, like phone, netbook, tablet or whatever) vendors, not just chipsets (as in 'Intel chipset' or something). Did I read it correctly? Cheers, -- Yves-Alexis ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo code in Linux kernel?
On 04/02/2010 12:32, Jeff Moe wrote: > On Thursday 04 February 2010 04:23:59 Marcin Juszkiewicz wrote: >> Dnia czwartek, 4 lutego 2010 o 11:53:22 Christopher Intemann >> napisał(a): >> >>> I came across this blog-entry [1] which is describing why the >>> Android kernel extensions were removed from the current kernel >>> version. I'm just curious: Where does Nokia/ Maemo stand? Are >>> there Maemo sources in the official Linux kernel tree at all? >> >> Good question. Some of nokia/Maemo code landed in linux-omap tree, >> some got into vanilla. >> >> But the question can be: is any of official kernel trees capable to >> provide fully working 2.6.33-rc kernel for nokia 770/n8x0/n900 >> tablet? > > At least for the N900 the answer is "no". The touchscreen driver > disappeared at 2.6.29: drivers/input/touchscreen/tsc2005.c > > A patch was made for re-inclusion a couple months ago, but it hasn't > hit any git trees that I've seen. There's likely a number of other > missing pieces as well, but that one is critical. So no support for > N900 in any kernel since at least 2.6.29. > And it might depend on what you call 'official kernel trees' too. There's a really nice page on n900 hw at http://natisbad.org/N900/n900-commented-hardware-specs.html where you can find information about kernel support. Cheers, -- Yves-Alexis ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Is mauku open source, i.e free or is in non-free?
On 26/01/2010 21:13, Graham Cobb wrote: > As a member of the Council I would say that we need to somewhere make it > clear > that by uploading a source package to maemo.org, you are giving maemo.org a > licence to redistribute that source and the binaries built from it (and that > you assert you have the right to give such a licence). Shall we add that to > http://wiki.maemo.org/Extras? What if people upload stuff don't have the right to give maemo.org that licence? If they aren't the copyright holder, there's no way they can give that right if it's not already allowed. Cheers, -- Yves-Alexis signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
On 21/01/2010 11:46, Jeremiah Foster wrote: >> For software and tools I agree. But processes will be very different. >> Maemo >> > is not aiming for a release every 18 months, Debian is. > The "official" release time period is 24 months. > There's no “time-based” release planned at all. What's planned (and for the moment not yet done) is “time-based” freezes, which is not the same thing. Debian releases ”when it's ready” (and usually late). Cheers, -- Yves-Alexis ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debhelper 7
On 16/12/2009 09:33, Marius Vollmer wrote: > (The main thing missing from debhelper IMO is better support for -dbg > packages.) Hmmh, what exactly do you need? Because with the tiny.rules, the only thing needed is the -dbg package declared in debian/control (dh_install takes care of everything). Though I don't have (source) packages with more than one (binary) -dbg package. Cheers, -- Yves-Alexis signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debhelper 7
On 16/12/2009 08:12, Rémi Denis-Courmont wrote: > On Tuesday 15 December 2009 22:10:39 ext Jeremiah Foster, you wrote: >>> * debian/compat: 7 -> 5 >>> * debian/control: Build-Depends: debhelper (>= 7) -> debhelper (>= 5) >>> * And maybe comment out a few dh_* calls from debian/rules, which >>> might not exist on level 5 >> >> One of the huge advantages of moving to debhelper 7 compat is that you can >> have your debian/rules files look like this: >> >> #!/usr/bin/make -f >> %: >> dh $@ >> >> Simple. You pass everything off to debhelper. > > That takes care of the packaging part, but not the building part or does it? > AFAICT, if you really want short and implicit rules, you could use CDBS. That > works fine with any debhelper from version 4 and up. > That's not exactly the place to do a cdbs vs. debhelper debate, but (with my debian hat on) I really prefer using debhelper 7 with override stuff than cdbs. It's really easier to fine-tune. Is there a reason why scratchbox is stuck with etch base system? In Debian we usually build packages for unstable using unstable. I can understand the distro hasn't exactly the same purposes, and that tracking unstable would be too much work, but why not at least upgrading too Lenny (which has debhelper 7, though not the version with dh_override_*) Cheers, -- Yves-Alexis signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Optification (was Re: PyMaemo (Python for Maemo) final release for Maemo 5 (Fremantle))
On mar., 2009-11-10 at 12:33 -0400, Anderson Lizardo wrote: > Nice to hear that! We decided to leave out the optification for the > final release, just not to delay it even more. But now I believe we > can work on it as an update through extras-devel (I just hope that > that QA process will take any possible regressions with the new > packages we upload). Hmhm so everything will install on OneNAND ? Or everything will install on eMMC ? -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Maemo5 on Beagle
On mar., 2009-10-27 at 08:21 +0100, tero.k...@nokia.com wrote: > > -Original Message- > > From: maemo-developers-boun...@maemo.org > > [mailto:maemo-developers-boun...@maemo.org] On Behalf Of ext > > Dirk Behme > > Sent: 26 October, 2009 17:53 > > To: maemo-developers@maemo.org > > Cc: Felipe Balbi > > Subject: Re: Maemo5 on Beagle > > > > Dirk Behme wrote: > > > Till Harbaum / Lists wrote: > > >> Hi, > > >> > > >> The download page for the zoom patches for maemo-beagle > > directs one > > >> to http://www.daimi.au.dk/~cvm/ which is the homepage of > > Carsten Munk > > >> who seems to be the wellknown stskeeps from maemo.org. > > > > > > I'm (dirk2) currently discussing with stskeeps @ #maemo :) > > > > > > http://mg.pov.lt/maemo-irclog/%23maemo.2009-10-25.log.html > > > > > > Maemo5 Nokia kernel seems to be 2.6.28 > > > > > > http://repository.maemo.org/pool/maemo5.0/free/k/kernel/ > > > > > > This seems to contain some (DSS2?) changes, which seem to be not > > > available as patch anywhere. E.g. it seems that Maemo5 SGX needs > > > function omap_dispc_set_plane_ba0(). > > > > Based on > > > > http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipe > > s/linux/linux-omap_2.6.28.bb?h=stable/2009 > > > > > > I built a kernel with > > > > http://people.freedesktop.org/~felipec/beagle/0001-DSS2-Export > > -omap_dispc_set_plane_ba0.patch > > > > (needs manual editing, doesn't apply cleanly to above 2.6.28 > > Beagle kernel, see attachment) > > > > If anybody likes to test it with Maemo5 (SGX), I can send the uImage > > (~2.7MB) > > > > If this doesn't work, we can try the inverse way (making > > Nokia kernel Beagle compatible, see below). > > I can take a look, I have a beagle sitting here on the desk. > > Carsten made a kernel yesterday based on the DSS2 patch (thanks to Felipe!). > It booted, had SGX working and even ran Xorg, but didn't output anything on > screen. > Framebuffer or Xorg settings are wrong, I'll ask someone who knows to use > their coffee break on it. > > But anyway a huge step forward :-) > Btw there's an ongoing work to port Mer on the TouchBook (http://www.alwaysinnovating.com) which is BeagleBoard based. Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SyncEvolution in Fremantle
Patrick Ohly a écrit : > Hello Maemo! > > It has been a while that I posted anything here. Ironically, since I > started working on SyncEvolution full-time beginning of this year, I > seem to have *less* time left compared to the previous years when I did > it in my spare time ;-) > > For those who haven't heard about it: > * SyncEvolution is a SyncML client synchronizing PIM data with > SyncML servers [1]. The versions <= 0.8.1 are available for > Maemo [2] and work with the builtin address book and the Dates > calendar. > * This year it became the sync solution in Moblin and switched to > the Synthesis SyncML engine [3], with the goal of using that > also as SyncML server on a desktop [4]. > * We have direct client to server synchronization working in the > development branch, without depending on closed third party > software [5]. > > I'd love to see the latest SyncEvolution releases packaged properly for > Maemo, and so do users [6]. 0.8.1 still works fine on the older Maemo > releases it is available for, but 0.9 has several relevant improvements, > for example synchronization with Google Contacts and a GTK GUI. > > I'm posting here because I hope that an interested developer or > maintainer will step up and take over packaging for Maemo. You can be > sure that this will have full support when it comes to merging patches > and including the Maemo port as first-class citizen in releases. > Eh, funny, I just posted yet another thread on talk (http://talk.maemo.org/showthread.php?t=33308) The syncevolution and libsynthesis packages have recently been uploaded to Debian (I sponsored them) and I would really be interested to be able to use them on both laptop and n900 (when I have one). So yeah, at one point I may give a hand for that to happen. Does the to-be-release 0.9.1 will do the direct sync without third party syncML servers? Cheers, -- Yves-Alexis ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder problem with optified library
On lun., 2009-10-19 at 22:01 +0200, Yves-Alexis Perez wrote: > On lun., 2009-10-19 at 22:26 +0300, Kamen Bundev wrote: > > Well, on the device and probably in autobuilder the /opt folder is > > actually a symlink to /home/opt... On the other hand maemo-optify > > produces direct /opt folder. > > That's the problem, dpkg won't replace a symlink by a real folder. I don't really know in that context, but I guess maemo-optify shouldn't create a real folder if it's a symlink in the device. Not sure I can help you more… -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder problem with optified library
On lun., 2009-10-19 at 22:26 +0300, Kamen Bundev wrote: > Well, on the device and probably in autobuilder the /opt folder is > actually a symlink to /home/opt... On the other hand maemo-optify > produces direct /opt folder. That's the problem, dpkg won't replace a symlink by a real folder. -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder problem with optified library
On lun., 2009-10-19 at 21:46 +0300, Julius Luukko wrote: > Selecting previously deselected package libgtkextra-x11-2.0-1. > Unpacking libgtkextra-x11-2.0-1 (from > .../libgtkextra-x11-2.0-1_2.1.1-3.1maemo4_armel.deb) ... > dpkg: error processing > /var/cache/apt/archives/libgtkextra-x11-2.0-1_2.1.1-3.1maemo4_armel.deb > (--unpack): > trying to overwrite `/opt', which is also in package base-files > dpkg-deb: subprocess paste killed by signal (Broken pipe) > > libgtkextra-x11-2.0 is almost directly from debian except for the > optification. It built fine in autobuilder and it is now in > extras-devel > [2]. I believe that no other package is using it, at least that was > the > case with diablo and chinook. Just wondering if in one of these packages the /opt is a symlink and on the other a real folder? Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] building an application with custom kernel-headers
On Thu, 2006-10-19 at 11:31 +0300, Eero Tamminen wrote: > > [sbox-fitz: ~] > grep > > > IFA_F_HOMEADDRESS /usr/src/su-18-kernel-headers/include/linux/rtnetlink.h > > #define IFA_F_HOMEADDRESS 0x10 > > Is this in the part of the kernel header that is not "exported" > unless you're compiling kernel source code? (or claiming > so with a define used for this) I don't really know what you mean here, but this works outside of scratchbox/maemo, and it works using not 'gcc' but 'gcc-3.4' (gcc is a link to sb_gcc_wrapper in /scratchbox/compilers/bin/ while gcc-3.4 is a pure arm compiler in /usr/bin): [sbox-fitz: ~] > file /scratchbox/compilers/bin/sb_gcc_wrapper /scratchbox/compilers/bin/sb_gcc_wrapper: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped [sbox-fitz: ~] > file /usr/bin/gcc-3.4 /usr/bin/gcc-3.4: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.4.17, dynamically linked (uses shared libs), stripped So I build my package using CC=gcc-3.4 Thanks, anyway. -- Yves-Alexis Perez ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] building an application with custom kernel-headers
Hi list,
I run into probleme trying to build an application which requires custom
kernel headers on scratchbox (0.9.8.5) using maemo rootstrap 2.0, cpu
transparency via qemu-arm.
I've built a patched kernel (which boots fine on the device), following
the Howto Kernel Compilation found on Maemo wiki. I've installed
su-18-kernel-headers too, and those headers are located
in /usr/src/su-18-kernel-headers/include in the scratchbox root.
I've checked that these headers have the correct files, with correct
definition.
The configure script tries to build a sample c file with a test on a
#define'd variable which exists in the custom headers files (and not in
the vanilla ones), and fails.
I tried with the sample c file by hand, using:
gcc -c -Wall -g -O2 -isystem /usr/src/su-18-kernel-headers/include
conftest.c
conftest.c contains:
8<
#include
int
main ()
{
#ifndef IFA_F_HOMEADDRESS
char *p = (char *) IFA_F_HOMEADDRESS;
#endif
;
return 0;
}
8<
and:
[sbox-fitz: ~] > grep
IFA_F_HOMEADDRESS /usr/src/su-18-kernel-headers/include/linux/rtnetlink.h
#define IFA_F_HOMEADDRESS 0x10
I guess gcc doesn't use correct kernel headers due to cross compilation,
but have not clue how to fix this.
If anybody can help me on this, it would be really nice.
Thanks & regards,
--
Yves-Alexis Perez
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
