Re: Mobile Linux should have COMMUNITY governance
ext robert bauer nyba...@gmail.com writes: The proposed alternative site (apps.formeego.com) seems to be a corporate-sponsored site from our own long lost friend, Nokia. I'd say that corporate sponsership of community controlled infrastructure is a very good thing, much better than corporate controlled infrastructure that tolerates some community activity. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle Community SSU
ext Mohammad Abu-Garbeyyeh mohammad7...@gmail.com writes: Unfortunately, while this might be the right way, it caused me some problems with the enabler package, so to work around it, a terminal window is started from HAM (postinst) and then the postinst exits, the user then has to exit HAM and go back to the terminal window to continue installation. Hmm, this sounds awkward. If I can, I would like to help you improve this. I haven't checked your enabler package yet, but off the top of my head, what about this: - You put a version 0 of mp-fremantle-community-pr into your repo that has the exact same dependencies as the PR-1.3 mp-fremantle-generic-pr meta package. - You make a enabler package that configures the domains and keys and everything, and also contains a little script that runs apt-get install mp-fremantle-community-pr=0 This will just swap mp-fremantle-generic-pr out for mp-fremantle-community-pr. - The script has a launcher icon and you tell people to run it that way. (Maybe this is the step that you want to avoid.) - There is also a 'real' version of mp-fremantle-community-pr in the repo, of course, and people can then immediately upgrade to it in HAM. This makes it so that the main upgrade runs inside HAM, which might be a better user experience than running it inside a terminal. I don't know if it actually works, but you can also put HAM into red-pill mode and maybe enable the apt algorithms. Then you should be able to see and install mp-fremantle-community-pr right inside HAM. To put HAM into red-pill mode, you need to edit ~/.osso/hildon-application-manager. Of course, you can also include a new version of HAM, or a completely alternative installer UI, in mp-fremantle-community-pr version 0. I guess I have overlooked something obvious, but maybe this gives you some ideas... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle Community SSU
ext Niels Breet ni...@maemo.org writes: Problem Mohammad faced here is that HAM holds a lock, so you can't run apt-get in the background. This is why he needs to open the xterm and ask the user to close HAM. Yes. But what about launching that script from a launcher entry instead of asking people to type something into an xterm? I think that inspires a bit more confidence. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Non-user/ packages and updating
ext Eino-Ville Talvala talv...@stanford.edu writes: This seems like an unfortunate situation in terms of bug fixes and so on - we think fcam-drivers is pretty stable, so hopefully we don't have to update it again anytime soon! You can make the fcam-drivers package visible in the UI, just like applications. Then you can release updates to it and people will see them. This is not ideal, since people might not understand what this fcam-drivers application is and why they have it, and if everyone does it, there might be too many packages in the UI, but it's an option. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Non-user/ packages and updating
ext Alistair Buxton a.j.bux...@gmail.com writes: This is, apparently, by design. No, not really. It's a known misfeature. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: X server / RECORD extension problem (Xnee)
Tamminen Eero (Nokia-MS/Helsinki) eero.tammi...@nokia.com writes: When I do: dpkg -x xnee_3.02-2maemo2_all.deb . all I see is some docs It's a virtual package depending on the actual binary implementation package. Virtual packages don't exist as archives, they are only mentioned in Provides. (Sometimes there is a virtual package with the same name as a real package, but that is best avoided.) ___ 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?
ext Ville M. Vainio vivai...@gmail.com writes: Well, that's certainly not the general understanding (inside Nokia) of how it should work. Do you care to elaborate so that we can escalate the issue (with the understanding that it's holiday period...)? Ville, if you escalate this, the right thing IMO would be to fix the Application Manager, make a new Maemo 5 release with it, and somehow 'force' people to update to it when they install a package from Ovi Store that needs dependencies resolved. I am here this week only, so let's find some time to get this going. ___ 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?
ext Ville M. Vainio vivai...@gmail.com writes: That comment doesn't apply since applications are downloaded from repository, triggered by .install file (unless there is a terrible misunderstanding somewhere). This is true for gratis packages, but paid packages are downloaded as Debian packages, not as .install files. (I confirmed that now by paying EUR 1 for angryman. :) 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. ___ 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?
ext Sascha Mäkelä sascha.mak...@gmail.com writes: So according your opinion, should I wait for this issue to be resolved at Nokia's end or should I try to make changes to my app? Don't wait for us, try to work around the problem on your side. The one suggestion I've been given several times is to statically include Qt Mobility, but I'm not so sure if that is a great idea and even if it was, I don't know how to do that. I would do what you have started this thread for: do without QtMobility. I'll reply to your original mail with some hints. When statically linking QtMobility, there might also be license issues. QtMobility is LGPLv2.1 (unless you have a commercial Qt license which I assume you don't), and that means that you can't really copy code out of it into your sources (which I assume are non-free), and even if you distribute QtMobility in your package, you need to satisfy the LGPL: static linking is not allowed (unless the user can do it, too), you need to provide source for QtMobility upon request, etc. Maybe Nokia gives an exception that allows static linking of QtMobility, and Nokia isn't likely to sue you over this anyway, but still, Nokia shouldn't really make the suggestion to statically link QtMobility without clearly stating that they give permission for that eventhough the license of QtMobility forbids it. ___ 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?
ext Sascha Mäkelä sascha.mak...@gmail.com writes: 1. Detectect if the device is Offline and give appropriate warning. 2. Detect if the device is connected and if not establish the connection. 3. If the connection is set to manual, the app needs to give the necessary prompt. 4. If the connection is set to automatic, it should connect without any prompt. These services are provided by libconic. There should be a libconic0-doc package in the Maemo 5 SDK repositories with the API documentation for it. So these, I believe, are the requirements of the Ovi Store QA regarding network connectivity. Now the question is how can this be done without using Qt Mobility (or any other library that is not included with PR1.2)? Is it even possible? Sure. QtMobility isn't part of the OS, which is causing all the pain here, and the bundled applications like the browser have to do the same thing, of course, without QtMobility. ___ 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?
ext Yves-Alexis Perez cor...@debian.org writes: 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. Another issue is scalability: we don't want to download the meta data for the whole Ovi Store during apt-get update. For Harmattan, we are putting a Ovi Store Adaptor into place which makes the Ovi Store look like a regular repository. The apt-cache search will find your paid packages and you can update them with apt-get upgrade, etc. ___ 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?
ext Sivan Greenberg si...@omniqueue.com writes: Hi Marius, On Thu, Jul 22, 2010 at 11:59 AM, Marius Vollmer marius.voll...@nokia.com wrote: For Harmattan, we are putting a Ovi Store Adaptor into place which makes the Ovi Store look like a regular repository. The apt-cache search will find your paid packages and you can update them with apt-get upgrade, etc. How is preventing unauthorized downloads maintained through this strategy ? When downloading a package, apt-get will also do that via the adaptor. The adaptor will do whatever is necearry to retrieve the temporary URL from the Ovi Store, and then immediately use that. ___ 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?
ext Yves-Alexis Perez cor...@debian.org writes: 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... I really can't say anything about the Ovi Store infrastructure... 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? It's not only the download time, it is also the size of the meta data that is stored locally and needs to be processed. I am thinking about making apt's cache updates fully incremental, so that the whole apt-get update is proportional to the size of the pdiffs, and we also use pdiffs for changes to /var/lib/dpkg/status... But that's more on the crazy side anbd the cache would still be quite big. Anyway, the device should support pdiffs just fine. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to to manually package Qt Mobility?
ext Attila Csipa ma...@csipa.in.rs writes: It's probably not a good idea but you can work around the issue like the Qt smart installer does - omit any non-base firmware dependencies, and use a loader. That way the install will succeed, and then via the loader you can apt-get/application-manager install whatever you need on the first run of the application. Ouch. I was thinking along these lines, and it is a bit shocking that people actually have done this and had to go to this length to work around a shortcoming in the Application Manager... I have to say I feel quite bad about this now. :( ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to to manually package Qt Mobility?
ext Sascha Mäkelä sascha.mak...@gmail.com writes: This is rather strange, since I was under the impression that apt-get would automatically download the missing packages. (The following might not be entirely accurate since I have no experience whatsoever with Ovi myself, and not much experience with the Fremantle Application manager.) There is unfortunately a big difference between installing a package from a repository and installing a package from a single foo.deb file. When installing a single foo.deb file, the Application Manager does _not_ automatically install missing packages, it only does this when installing packages from a repository. Since Ovi delivers single foo.deb files to the device, their dependencies are unfortunately not automatically satisfied. You just get an error that they are missing. This clearly sucks, and it only works this way because I have pretty much totally neglected installation from single deb files. It's a different code path in the Application Manager, and at least from me, it didn't get any love. The reason for this negligence is that I didn't think that anybody would want to install single foo.deb files, and if I remember right, the feature was actually disabled at some point. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Optification in MADDE, again
ext Tomi Ollila tomi.oll...@guru.guru-group.fi writes: On Fri 02 Jul 2010 12:31, Martin Storsjö mar...@martin.st writes: dh_fixperms, which write the list of files for tarlisted, doesn't recognize symlinks at all, but this can be fixed with the attached patch. There is a reason for that: Windows (below 7) (NTFS) filesystem does not regognize symbolic links (properly); Generally, any software packakeable with MADDE on linux should be also packaeable on Windows too... Wha?? You guys have ported debhelper to Windows? The mind boggles... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Optification and plug-ins
ext Cornelius Hald h...@icandy.de writes: On Tue, 2010-06-01 at 08:43 +0300, Marius Vollmer wrote: ext Cornelius Hald h...@icandy.de writes: as there has been no news since February, I think I should see whether or not someone is still responsible for this bug: https://bugs.maemo.org/show_bug.cgi?id=7707 Yep, that's me. Thanks for the reminder, I'll get back to this soon. Great to hear that you're still on it :) However, if this is simply a weird corner case that won't be handled, please close the bug to let us know that we have to roll our own solution. No, the code to handle this is in maemo-optify, it just hasn't been released (and carefully tested) yet. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Optification and plug-ins
ext Cornelius Hald h...@icandy.de writes: as there has been no news since February, I think I should see whether or not someone is still responsible for this bug: https://bugs.maemo.org/show_bug.cgi?id=7707 Yep, that's me. Thanks for the reminder, I'll get back to this soon. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Dependency problems after PR 1.2 update to extras builder
ext Robin Burchell virot...@viroteck.net writes: Things as I understand it: - Qt 4.5 on Maemo5 had no API/ABI compatibility guarentees. - Qt 4.6 took liberal advantage of that to change and fix some rather suboptimal parts. This might have been handled better, though, with a proper soname change etc. There are ways to cleanly break an interface, still painful, but at least sterile. In general, I think it is not useful to release an SDK update earlier than the OS. The way they are joined at the hip, they need to be released together. (Yes, in an parallel universe, SDK and OS would be more independent. But they are not and we should not pretend they are.) It is of course better to release earlier than later. Thus, if we want to release the SDK early, we simply need to release the OS with it, as a beta. But even if there is a SDK release with a corresponding OS beta release, I'd say it should not be installed in the Extras autobuilder. People can try out the new SDK and OS beta by themselves, we don't need to force them to use it. The Extras autobuilder should build for the most recent release of the OS. (In my dreams, the OS updates would be developed in extras-devel as well, end-users would eventually SSU from extras, and the SDK as such would not exist. We would still have the problem of how to make a binary that is compiled against Qt 4.6 run with Qt 4.5, but everybody except us has that figured out.) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Dependency problems after PR 1.2 update to extras builder
ext Marcin Juszkiewicz mar...@juszkiewicz.com.pl writes:
Is there a way of specifiying to use the older packages?
No such option.
The problem are the automatic generated dependencies, if I understand
things right.
I.e., you build against libqt4-core version 4.6.2~git20100224, and the
resulting package ends up having this:
Depends: libqt4-core (= 4.6.2~git20100224)
(Among others, of course.) This originates from this in your source
package:
Depends: ${shlibs:Depends}
The text libqt4-core (= 4.6.2~git20100224) comes from the libqt4-core
package itself that is installed while building. But: You can overwrite
it if you know better what dependency you want to have.
You do this by putting a debian/shlibs.local file into your source
package. It might look like this:
libQtCore 4 libqt4-core (= WHATEVER-YOU-WANT)
ETC...
Of course, this only changes the text in the Depends field of your
package. You must make sure that your program actually runs with the
older version of Qt even when it has been compiled against the newer
version.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Ask for removal of some packages from Extras Fremantle repository
ext Luarvique L. Luarvique luarvi...@gmail.com writes: This whole talk about any repository but Extras is unsafe and evil is mostly bullshit, and I think most users are smart enough to know it. It might be mostly bullshit, but not entirely. If we teach people that it is normal to go hunting for alternative repositories, we substantially increase the risk that they run into unsafe and evil ones. The difference is between one or maybe three well known sources, and uncounted mostly unknown sources. You can have a million security frameworks on your device, but as long as you go and install stuff 'randomly' from the Internet, you are running a high risk. One of the first things that you learn when you grow up is that it is not a good idea to put everything into your mouth that you find on the ground. While nobody should be forced to funnel his packages through the few well known repositories, our users should more or less demand to find all the good stuff in them, because they know that these repositories are well-maintained and backed by a community: packages are not abandoned, and they can expect them to be updated when necessary. Thus, we should market the advantages of a centralized repository to our users (down to making adding new repositories with .install files more scary, but still fair), and work to reduce repository fragmentation by seeking out the 'rogue' ones and copying their packages into ours, if legal, and subject to the same QA as other packages, of course. This might also be a good opportunity for some of us to eat our own dog food. If would be great if the people who drive the maemo.org QA process would back this up by maintaining a good number of packages themselves. (Maybe they do, I really don't know.) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Ask for removal of some packages from Extras Fremantle repository
ext luarvi...@gmail.com luarvi...@gmail.com writes: [...] What I do see though is that the Extras admission/promotions processes have become so bothersome to developers that they border on hostile. I don't have an opinion on this, since I am not at all involved in any of the specifics. (I have no packages in extras, for example.) In relation to that, I would like to remind everyone that the life does not stop at Extras: it is *ok* to create and maintain your own repositories. If Extras management would like as many developers as possible to use Extras, they have to make actual changes to the admission/promotion process rather than continue repeating the everything but Extras is evil mantra. Yes, very true. I didn't want to argue against this; sorry if I came across as defending the current QA process. I don't know the details of it, but I fully expect myself to agree with you if I would look into the details. One of the first things that you learn when you grow up is that it is not a good idea to put everything into your mouth that you find on the ground. Another thing that you learn when you grow up is that grownups generally prefer making their own decisions rather than allowing their parents to continue making decisions for them. Yes, and as you grow up more, you start taking responsibilities for others and then you see that your parents weren't all that wrong back then. Thus, we should market the advantages of a centralized repository to our users (down to making adding new repositories with .install files more scary, but still fair), and work to reduce repository fragmentation by seeking out the 'rogue' ones and copying their packages into ours, if legal, and subject to the same QA as other packages, of course. So, but I am afraid this is not exactly the first thing you should do. :) Yes, I agree. I just don't feel comfortable talking about the QA process, since I know nothing about it. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-developers Digest, Vol 59, Issue 25
ext Urho Konttori urho.kontt...@gmail.com writes: Also, the current model of centralized gigantic repository does not scale up too well. Just look at the state of using extras-devel is on the current devices (hint: slow pain). [ Urho, thanks for this opportunity to talk about how we want to make package management kick ass again. You guys might think we have arranged this (Urho sits two offices down the corridor from me), but we really haven't! ] I don't think the centralized nature is a problem here. Our current processes and implementations might not scale well enough, but getting rid of a centralized repository will not help much, if at all. The resources needed to maintain a centralized repository can be quite easily parallized to make the repository itself scale: there can be many buildbots, many mirrors, a CDN, many testers, and many maintainers. Now, the repository infrastructure and the processes around it can suck, of course, and putting another better designed and maintained repository into place might be needed. But that's only better because this other repository is better by itself; it's not better because we now have two of them. Shutting down the original sucky repository would be better still (but might not be easy, of course). Distributing the packages over many repositories mostly increases coordination overhead. It doesn't help to scale. HAM still has to deal with the same number of packages, for example. (And yes, HAM sucks and badly needs some love, no argument from me against that.) For HAM performance, the important variable is the number of available versions, not the number of repositories. You can regain performance by reducing the number of available packages and versions. Forgetting about repositories altogether and installing everything from standalone .debs is one way to do that, but it's not a good way. I believe there is a better way to make package management delightful: We only let HAM see a (consistent) subset of all available packages, and we make it possible to change that subset very efficiently at run-time (at UI speed without the need for any Updating please wait progress bars). That subset would include only the installed packages plus the ones that the user is currently interested in. Discovering packages that the user might be interested in is done without help from apt, via other means. We are currently writing code for this. We don't have all the pieces in place yet, but we have some: - The x-apt package in Fremantle extras-devel. This is Harmattans version of apt, repackaged to be installable in parallel to Fremantle's version of apt. The modifications currently include support for deb-exec entries in sources.list; this allows you to easily use custom protocols between apt and repositories for downloading the Packages file, etc. Today I'll add the patch for storing the Maemo specific flags in apt's binary cache. This allows us to do our extra OS meta package gymnastics without having to read the Packages files. http://maemo.gitorious.org/maemo-pkg/apt/commits/x-apt - The mini-pacman library (not yet in extras-devel). This is a minimal wrapper of libapt-pkg, with a very simplistic API. Of course, it actually uses x-apt, not the platform apt. It is also the experimentation ground for different algorithms that should get rid of some of the annoyances of the current HAM: better error messages, updating the OS when that helps, more agressively in general, etc. http://maemo.gitorious.org/maemo-af/mini-pacman/trees/master/src - A maemo.org specific 'discovery client'. It interfaces with downloads.maemo.org over a custom protocol for browsing available applications. Right now it passes .install files to HAM for the actual installation, and my plan is to hook it up with mini-pacman instead and then optimize the hell out of the whole stack. (Haven't seen the code yet myself, Daniel Wilms and Niels Breet should know more.) [...] I really do thing we have started to make our home our prison Then we should remove the bars and locks. Tearing down the whole house and going back up the trees would be overreacting quite a bit, no? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-developers Digest, Vol 59, Issue 25
ext Jeremiah Foster jerem...@jeremiahfoster.com writes: One huge issue with the repository is the tool used on the backend: apt-ftparchiver. This tool cannot automatically remove debs and source packages, causing huge disk bloat (some packages have four or five versions sitting on the repos.) I think apt-ftparchive is not supposed to do this, it only creates the indices. Or in other words, it does not install files into the repo, so why should it remove them? I have tried to fix this by installing a set up for reprepro - a state of the art repository management system. Reprepro is certainly nice, I had some good experience with it in the past. I hear it can generate .pdiffs now etc. This work has been largely ignored by the Nokia team running the repos, much to my frustration. Yes, Nokia is good at that. ;-) The danger is of creating a fork of the APT process. Using upstream tools would probably be wise - your work would help everyone. Yes, I will be careful. The changes will be source compatible, minimal, and hopefully well isolated. If you are interested, please check out the debexec.patch. And we are only in this for the short run, MeeGo will kick this all into the bucket anyway. Then we should remove the bars and locks. Tearing down the whole house and going back up the trees would be overreacting quite a bit, no? You'll need to allow the community to have more say on how the server infrastructure is run. Currently you need an NDA, proprietary tools are used, and access is strictly limited. This is the opposite of open source. Sounds bad indeed. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Deleting Project PyGTKEditor from Garage
ext Nils Faerber nils.faer...@kernelconcepts.de writes: What would probably help here is to create a page on the Maemo Wiki listing all known external feeds and what can be found in there. This would make changes like this pretty obvious for people looking for it. Even if you do that, it is better to remove obsolete versions from the Extras repository. There is no point in keeping obsolete stuff and hoping that people will figure out by themselves to avoid it. If you want to keep them, someone needs to step up and take over maintainership of the packages for maemo.org Extras. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: /etc/init.d/ssh stop does not stop ssh on the N900
ext Joerg Reisenweber jo...@openmoko.org writes: If the script doesn't work as everybody would expect, then it shouldn't be there at all. It's a 'conffile', so it will be left on the device even if you remove the package. Also, you can't really change it by putting a newer version in your package since the user might decline to have his version overwritten. You would need to put code into your postinst to fix up anything that wrong with a conffile without destroying user changes. It's generally a bad idea to put significant magic into conffiles, for these reasons. Files in /etc/init.d/ are probably the worst critters in this regard. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: /etc/init.d/ssh stop does not stop ssh on the N900
ext Dieter Plaetinck die...@plaetinck.be writes: On Wed, 24 Mar 2010 14:21:37 +0200 Marius Vollmer marius.voll...@nokia.com wrote: ext Joerg Reisenweber jo...@openmoko.org writes: If the script doesn't work as everybody would expect, then it shouldn't be there at all. It's a 'conffile', so it will be left on the device even if you remove the package. [...] init scripts are config files? what? They are 'conffiles', and are handled specially by dpkg. I agree with what Joerg said. init files are for stopping/starting/reloading/.. daemons (not for configuration), and they should just work. Yes, I was just pointing out that removing or changing /etc/init.d/ssh in the ssh package might not do what you expect. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Ask for removal of some packages from Extras Fremantle repository
ext Attila Csipa ma...@csipa.in.rs writes: On Tuesday 23 March 2010 01:00:19 Gary Birkett wrote: why doesn't HAM allow somebody to use a later provided version from Beniots own repository? there would be nothing wrong with leaving everything existing and Beniot can get what he wants by still offering users the opportunity to add his own repository and gain later updates and we retain the polished solid versions available for regular users. There was some mention of this previously. Basically, the issue is authenticity (package hijacking avoidance, whether intentional or not), and/or generic cross-repository FUBAR avoidance. Imagine what would happen during the Qt4.5 to Qt4.6 transition if we had external repositories containing apps referencing Qt. Yes, exactly. I originally put the package domain system into HAM as an attempt to reduce the 'repository mess'. Of course, this prevents packages to legitimally move from one domain to another, which is sometimes wanted. The domain system is not secure: any package can modify it, you just have to convince users to install that package. But that modification at least does not happen by accident. Now, we might end up with a domain mess when people really start creating their own domains. I hope that that does not happen, but if it does, we should probably improve how HAM determines which domain dominates which other domains, and maybe even involve the user in this. This is my neutral view as a provider of some of the technology. Of course, the maemo.org Extras repository is The One, and I think it is really really bad when people move their packages out of it. As has been said, a good reaction of the maemo.org community would be to just take over maintainership of those packages, and essentially copy them back into maemo.org Extras whenever a new version appears out there. This should not be a lot of work if the package doesn't need significant improvement to pass the QA criteria, and if it does, it can just be left out if nobody wants to do that work. That would be a win for everybody: Benoit can publish his versions in his own repository/domain and doesn't have to bother with the maemo.org processes. Still, his packages end up in maemo.org Extras, and might even be improved in the process. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Residual configuration after package reinstallation
ext Attila Csipa ma...@csipa.in.rs writes: I'm not sure how the HAM prompts (or doesn't) for config file conflicts, HAM passes --force-confold to dpkg. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Building Maemo OS from Source.
Stoppa Igor (Nokia-D/Helsinki) igor.sto...@nokia.com writes: No at all: it's about standardization. The device must support a certain set of features and provide well defined APIs. So if a device is MeeGo compliant, it will be advertised as such. In my view, MeeGo is a development effort, not a standardization effort. Standards might follow, in the form of new or updated LSB modules, but MeeGo itself is foremost a concrete collection of software, not a API standard, just like its forebearers Moblin and Maemo. Thus, MeeGo lives next to Fedora and Ubuntu, and remixes much of the same software in a slightly different way. It is not in the same category as POSIX, LSB, and FHS. Now, standards are important, too, but secondary. If someone with enough clue sits down and writes down a Mobile LSB module that actually gathers traction outside of MeeGo, then that would be a good thing. But that is not what MeeGo is primarily about. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Building Maemo OS from Source.
ext Jeremiah Foster jerem...@jeremiahfoster.com writes: On Mar 22, 2010, at 7:47 AM, Marius Vollmer wrote: In my view, MeeGo is a development effort, not a standardization effort. I am not convinced that this is true. It looks like MeeGo is going to track upstream closely with few customizations. It is going be be more of an integration that a distribution. In that regards, it leans closer to a standard linux instance than it does a separate distro. Hmm, still, MeeGo is surely going to be a collection of software that is maintained, released, and distributed. There will be documents about it, but the primary product of the joint Intel/Nokia effort is surely going to be mostly software, and not PDFs or--deity beware--PowerPoints and a certification process. Or did I really understand things wrong? Thus, MeeGo lives next to Fedora and Ubuntu, and remixes much of the same software in a slightly different way. It is not in the same category as POSIX, LSB, and FHS. The value it will have though is as a building block - not as a finished distro like Fedora or Ubuntu. I think it is important that MeeGo is a viable OS on its own, to attract more people. The content draft says that it will: it goes all the way up to a graphical desktop environment, including a few applications, and maybe even a browser. If I become interested in MeeGo, and the first thing I have to do is to decide which of the many vendor versions to actually use to get something useful, I might already be put off. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Icons are just a few bytes, right ?
ext Alberto Mardegan ma...@users.sourceforge.net writes: It would be nice to have a server-side logic, that generates the Packages file dynamically: the client gives a package name (and optionally a version), and the web engine generates the Packages file which enables downloading of this file, it's Depends:, Recommends:, Suggests:, and nothing else. I don't know much about APT, maybe something of this kind exists already? It doesn't exist yet, but that is exactly the plan we have for Harmattan. The first little (quite untested) building block is deb-exec. The apt-get in Harmattan now understands sources.list entries of the form deb-exec PROG and it will run PROG --packages to get the Packages file (and PROG --get FILE to eventually download a specific package file). The idea is that PROG would use a little database of its own to determine what should be downloaded. This database is maintained by a new 'discovery client' that uses whatever protocol it wants to 'discover' new interesting packages. Code is here: http://maemo.gitorious.org/maemo-pkg/apt/commits/maemo The current plan is to make a package of this that can be cleanly installed on Fremantle next to Fremantle's native apt version. The next building block will be to allow apt to temporarily use small Packages files without having to recreate the whole binary cache. This would be used by the discovery client to efficiently check dependencies etc for packages that apt doesn't yet know about. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Icons are just a few bytes, right ?
ext Tor lists.th.arnt...@gmail.com writes: It'll work for simple installs like that, but you lose what's known as 'the power of apt'. Not necessarily. You can keep the power of apt even if you only see a subset of the whole distribution. This is what happens when you have only main in sources.list on a Debian system, and we want to do the same, just on a much finer grained level. The idea is that once you discover a package somehow (regrettably without help from apt), that package plus all other packages that are mentioned by it (recursively) become visible to apt. Thus, what you see is always a consistent subset of the whole distribution, and apt can do its magic within it. Or in other words, discovering packages via apt-cache search or via debtags is a power of apt that we are willing to sacrifice if you gain significant better scalability. Users can of course always opt to let apt see the whole distribution. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Icons are just a few bytes, right ?
ext Attila Csipa ma...@csipa.in.rs writes: What about removing old versions completely? Old versions are useful, but only quite rarely. If you want, you can keep a separate extras-history repo with all versions ever that people can use if they really need to get obsolete versions. Certainly a good option, but perhaps not as clear-cut as in the case of icons (=not 100% useless as old icons). There are a few potential problems with old ver removal, though. Some might depend on newer versions of libs than others, so not every dupe is superfluous and this check needs to be very careful in order not to break other apps. This is not how apt (and the Application manager) works. From all the available versions of a package, apt selects one upfront as the candidate and then sticks with that. The only decision it makes is between installing that candidate version, keeping the version you have already installed, or removing the package altogether. It will not reconsider which version should be the candidate based on dependencies between packages. Old versions are only useful with apt when you explicitly do things like apt-get install libfoo=1.23-5 This _is_ useful, but only during debugging. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Icons are just a few bytes, right ?
ext Attila Csipa ma...@csipa.in.rs writes: There are probably many better ways to do this, but a quick and dirty solution would be to remove the icon from the older version in the repo when a new version is pushed to the repo. What about removing old versions completely? Old versions are useful, but only quite rarely. If you want, you can keep a separate extras-history repo with all versions ever that people can use if they really need to get obsolete versions. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: External Repository and HAM
ext Victor Manuel Jáquez Leal cey...@gmail.com writes: 2010/3/8 Marius Vollmer marius.voll...@nokia.com: Then you can activate the red-pill mode and unset the Ignore packages from wrong domain setting. Red pill mode user interface flow was removed from HAM. Ahh, yes, sorry. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: External Repository and HAM
ext Benoît HERVIER kher...@khertan.net writes: As i'm the maintainer of this packages in extras repository, i need to found a solution : What is the exact problem that you try to solve? Do you want to install your own version from your own repository on your own device? Then you can activate the red-pill mode and unset the Ignore packages from wrong domain setting. You can also of course just install the package with apt-get install in xterm or over ssh, which would guess is more convenient during development. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: External Repository and HAM
ext Benoît HERVIER kher...@khertan.net writes: The purpose is to migrate my softwares from extras to my own repository as i ll not push anymore my applications to extras, but only on my own repository. Ahh, ok. This is not something that is well supported (as you have found out), and I believe the Maemo community discourages this. Maybe there is a possibilty for you to keep your package in Extras? One option is to change the package name, and maybe use a Conflicts/Replaces pair to kick out the old package on users devices when the new one is installed. You should also ask for the old package to be removed from Extras, I'd say. Another option is to create a new domain for your repository. So current user cannot update actually my softwares with ham. Saying them to apt-get upgrade from xterm is a solution, but not the best one. What about the red-pill mode setting? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: External Repository and HAM
ext Thomas Perl th.p...@gmail.com writes: 2010/3/8 Marius Vollmer marius.voll...@nokia.com: ext Benoît HERVIER kher...@khertan.net writes: The purpose is to migrate my softwares from extras to my own repository as i ll not push anymore my applications to extras, but only on my own repository. Ahh, ok. This is not something that is well supported (as you have found out), and I believe the Maemo community discourages this. Maybe there is a possibilty for you to keep your package in Extras? I have a similar problem. If the Maemo community wants developers to publish their packages in Maemo Extras, please make sure that problems with the autobuilder are dealt with in a reasonable time frame. Fair enough. If this issue remains, I would recommend to set up one alternative repository and create a new package domain for it. Such a fork would be painful, and I really hope we can solve the technical issues. But, just to be perfectly clear: the package domain system was explicitly designed to allow clean forks, and once you have set it up for your repo, it will protect your repository against 'accidental' uploads to maemo.org just as it protects maemo.org now. I haven't published a new version of MaePad in Extras for nearly a month now, because of autobuilder issues (with sharing-dialog-dev): https://bugs.maemo.org/show_bug.cgi?id=9070 I agree that it is unreasonable to let this bug remain untouched for so long. [...] and because of the trust domain issue, this might result in several people requesting to have their packages pulled from Extras in order to be able to distribute their packages from another repo [...] The domain check is only done when updating a package; it will allow the initial installation to come from any repository whatsoever. It was designed to prevent people from 'hijacking' packages by accident, by locking updates to the repository that the initial version was installed from. But of course, having a old version of a package in Maemo Extras that is no longer maintained isn't good for anything, so it is better to remove it. Alternatively, you could upload one last version to it that somehow advertises your new repository (or even automatically configures your new repository and package domain, but you didn't hear that from me, and if you do that, please don't do it silently). ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: External Repository and HAM
ext Benoît HERVIER kher...@khertan.net writes: (or even automatically configures your new repository and package domain, but you didn't hear that from me, and if you do that, please don't do it silently). Anyway it ll not past QA Testing :) Why wouldn't it? Do we have a policy against this? Ahh, you probably mean there is a chicken-and-egg here: you can't upload to Extras anymore in any case. Maybe you need to cripple your last release to get it to build and past QA, but maybe that is worth it... create a new package domain for it. Have you some explanations on how to do that ? or maybe link ? I think I'll write something up in the immediate future. Lucas Maneos has done it for Diablo updates, please try to Google that. Very roughly: - create a repository - create a GnuPG keypair and sign the repo with it - create a package that - installs the public key with apt-key add - drops a file into /usr/share/hildon-application-manager/domains/ that looks like this: config domain nameunique-name/name keyfingerprint-of-keypair/key trust-level250/trust-level /domain /config - create a .install file for the package above - tell people to install that .install file. After this, you can upload packages to the repository and HAM will allow them to update packages from Extras. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: External Repository and HAM
ext Graham Cobb g+...@cobb.uk.net writes: All these are **real** problems we experienced in the early days of Maemo and are the reasons we created the common repositories and put a LOT of pressure on developers to use them. By having a common repository, there is always only one copy of the shared library, libfoo. To be fair, libraries do not _need_ to be shared, sharing them is an optimization. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: AT command AT+CSMP=1,167,0,8 not possible on N900
ext 白い熊 maemo-developers_maemo@sumou.com writes: [... I don't know how to effectively spawn an asynchronous process in Emacs and have it wait for its output, [...] Check out process filters: http://www.gnu.org/software/emacs/manual/html_node/elisp/Output-from-Processes.html#Output-from-Processes ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: AT command AT+CSMP=1,167,0,8 not possible on N900
ext 白い熊 maemo-developers_maemo@sumou.com writes: I think the reason is, as the page says: When a subprocess terminates, Emacs reads any pending output, then stops reading output from that subprocess. Therefore, if the subprocess has children that are still live and still producing output, Emacs won't receive that output. Ahh, tough. Maybe you can wrap pnatd somehow so that the sub-process that Emacs sees does only exit at the very end. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community updates for diablo (specifically Application Manager if nothing else)
ext Lucas Maneos ma...@subs.maneos.org writes: The story so far: - mined a bunch of patches from bugs.maemo.org - built some updated packages with the above - got Nokia's blessing to modify and redistribute osso-software-version-* - set up a test repository. Great! The missing piece: making the updates installable via application manager so we can invite some brave souls for testing. The problem (as I understand it) is packages switching domains. The updated versions come from a repository signed with a different key to the nokia-system one, which makes the application manager ignore them. Based on http://hildon-app-mgr.garage.maemo.org/repos-stable.html: Domains have a 'trust level' associated with them. Domains with a higher trust level are considered to dominate other domains and the AM will allow a package to silently move from a domain to a dominating one. I had assumed that setting a higher trust-level would allow domain switches to happen, but this doesn't seem to be the case :-( It should work like you expect it to. For clarity, I'm testing on a freshly-reflashed 5.2008.43-7 N800 with the following added to /etc/hildon-application-manager/domains: domain namecommunity-updates/name trust-level600/trust-level key[...]/key default/ /domain and default/ removed from nokia-system. This looks correct. I suspect that the Application manager just doesn't recognize your repository as belonging to this domain. You also need to install the matching public key. What does # apt-key list output? I can try to find a Diablo device to debug this a bit. It is a bit icky to get all the configurations just right, but once you do, things just start working silently. Every workaround I can come up with is unworkable at best, the only semi-viable one being to patch the application manager but this has the obvious chicken-and-egg problem of how to publish the patched version so users can install it. You can tell people to install it in red-pill mode (or on the command line). In red-pill mode, the domain check can be overruled by the user. I may be missing something obvious, so any ideas welcome. It might just be the missing public key. Without it, the signature on your repo will not be recognized as valid, and it will be associated with the unsigned domain. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community updates for diablo (specifically Application Manager if nothing else)
ext Lucas Maneos ma...@subs.maneos.org writes: On Mon, Mar 01, 2010 at 08:12:23AM +0200, Marius Vollmer wrote: It might just be the missing public key. Without it, the signature on your repo will not be recognized as valid, and it will be associated with the unsigned domain. After a good night's sleep and some caffeine, I think I found the problem (between the chair and the keyboard). A paste error in the key fingerprint will also have a similar effect (falling back to signed), sorry for the noise. Yep, that's also an important thing to get right, obviously. I am happy that you have figured it out! If anything else comes up, don't hesitate to ask, of course. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
ext Dave Neary dne...@maemo.org writes: Then a new version of the SDK comes out, which is not backwards compatible. A number of potentially bad things can happen: I agree with your points in general, but I want to qualify them a bit. There are two issues: - I think it is very important to be able to release new OS versions and new SDK versions that add APIs. - I also think that it is important to be able to remove APIs in a controlled way, but much less so than being able to add APIs, and we can leave that for later, once we have figured out how to add APIs. 1. New uploads get compiled with the new SDK, and get downloaded onto phones with the old OS, where they don't work. This is one kind of bug: the new SDK has added APIs compared to the old API, and applications that use the new SDK wont run on OS versions that doesn't have that API. Some will not work, and some will not even install, but most of them should install and work. New uploads should only not install or work (by necessity) when they actually use the added API. If they don't use any of the added API, they should install and work with the old versions of the OS. Our SDKs are not very good at producing the necessary dependency information for this (i.e., our library packages don't use dpkg-gensymbols, and we do not maintain the -V option of dh_makeshlibs), and as a result, almost all packages will erroneously refuse to install into a old OS when they have been compiled in a new SDK. This is a bug in the SDK (i.e., in the tools and in the packages), it is unfortunately _not_ trivial to fix, but it is very worthwhile to fix it. (RPM does it differently, so maybe this isn't actually worthwhile to fix, but let's ignore that for now...) We should at least check each new SDK release for undesired changes in the shlibs files. 2. Developers working with the old SDK upload applications which don't even build with the new SDK This is a different kind of bug: this will happen when the new SDK has removed APIs compared to the old SDK. It's a bug in the SDK and should be fixed. 3. To mitigate 2, we decide that all Extras apps need to be recompiled with the new SDK, [...] That would be foolish, and we should not do it. As you say, we would run into the SDK bug responsible for category 1 above. We can and should avoid that by not recompiling applications just because the SDK has been updated. Instead, before accepting a SDK release, we should check whether it can still compile all the Extras apps. If not, we have found a bug, either in the SDK or in the Extras app. That bugs needs to be fixed, and there wont be many of these. All of these push inconvenience to the phone user application developer - all unnecessary overhead, especially if the APIs haven't changed and there are issues with run-time library versions (as we saw with PR 1.0 to 1.1). Agreed. The only way to avoid badness when upgrading the SDK in a not-backwards-compatible way is to have scratchbox, every developer copy of the SDK, and the N900 firmware all upgrade at the same time. That's fortunately not the only way, although the way outlines above isn't particularily easy. The established GNU/Linux upstreams and distributions have this pretty much under control. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
ext David Greaves da...@dgreaves.com writes: My wife must have done an 'ignore' on a Maemo5 update sometime in oct/nov. The device never reminded her again. She only got pr1.1.1 because she noticed my device made a sound on account connections and hers didn't... I did 2 upgrades in succession. Normal users wouldn't have even noticed. That's a bug in the ignore machinery: I think we only store which packages have been ignored, but not which versions. This means that if you ignore a OS update, you will never be notified again about OS updates ever. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
ext David Greaves da...@dgreaves.com writes: That's a bug in the ignore machinery: I think we only store which packages have been ignored, but not which versions. This means that if you ignore a OS update, you will never be notified again about OS updates ever. Has a fairly big impact on the assumptions being made including those who will never see the update that fixes the bug... Yes, I agree. Back then, I was thinking that it would be annoying to notify people about every single subsequent update if they have ignored the first, but I have changed my opinion now... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
ext Martin DeMello martindeme...@gmail.com writes:
How do I clear out my ignore history?
Try this:
$ rm ~/.hildon-application-manager/{seen,tapped}-updates
We don't really keep a history of what has been ignored, just a brief
record of what has been shown in the Updates view. This is compared
to /var/lib/hildon-application-manager/available-updates to drive the
notifier icon.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
ext Michael Cronenworth m...@cchtml.com writes: If a user has access to downloading apps, then they will be notified of the Maemo update. If they want a new app, they must update Maemo, but they can continue using their old apps as long as they want. Refusing to update because of a personal preference should be discounted. Security updates, new features, and significant bug fixes should trump any personal preference about updates to Maemo itself. I agree, but the Application manager is unfortunately less than helpful in guiding the user through a required OS update. If a OS update is needed to install an application, the Application manager will only give a cryptic error message. This needs to be fixed, obviously. There are plans, but neither commitment nor schedules... :( ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PPA's?
ext Ville M. Vainio vivai...@gmail.com writes: I find it hard to see anything wrong with PPA's as such, I am one of the guys pushing for a central repository, but I can't see anything wrong with PPA's either, as long as the following is part of the code of honor of people maintaining such PPAs: - A PPA is not used to distribute the 'final' version of a package to all users of a Maemo device. E.g., the main download portal of maemo.org should not advertise packages in PPAs. - All PPAs are known to the maemo.org community, and their maintainers allow NMUs to them, subject to the same rules as NMUs in extras-devel. - Any combination of PPAs must yield a consistent distribution. More concretely: - Packages in one PPA should not depend on packages in another PPA - and they should explicitly declare all conflicts they have with packages in all other PPAs. PPAs _can_ contain overlapping packages (e.g., one PPA has a higher version of a package than another PPA, or in extras-devel), but not by accident. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PPA's?
ext Jeff Moe m...@blagblagblag.org writes: Right now things are just in random locations (for me and others). It would be nice to have it all unified. extras-experimental? :-) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PPA's?
ext Anderson Lizardo anderson.liza...@openbossa.org writes: On Fri, Feb 5, 2010 at 4:28 AM, Marius Vollmer marius.voll...@nokia.com wrote: - All PPAs are known to the maemo.org community, and their maintainers allow NMUs to them, subject to the same rules as NMUs in extras-devel. Sorry to hijack the thread, but where are these NMU rules in extras-devel ? Until now I never knew there were NMU rules for Maemo... (I am not sure if there are any, I was just saying that the same rules should apply to PPAs.) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo Base Port documentation
ext Marcin Juszkiewicz mar...@juszkiewicz.com.pl writes: Which version of Maemo it covers? Rather not Maemo6 as it had to be Qt based and pdf talks about GNOME GVFS. That's just a minor inaccuracy. Maemo 6 will use GIO and Gvfs. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debian Etch, Rebuilt: 6,451 .debs for Maemo 5
ext Jeff Moe m...@blagblagblag.org writes: * I rebuilt all Debian Etch source packages with the Maemo 5 SDK and sdbmock. Cool! * 10,220 Source packages processed. * 6,451 .debs produced. This means there were a lot of build failures (as could be expected). Mining the failures would be interesting, too. I suppose a lot are due to missing build dependencies, but some have probably failed in more interesting ways. Do you have the build logs online as well? * They have not been run through maemo-optify yet--I will test the fix for the recursive symlink bug[1] when ready. There should be a fix any day now... * I could batch import packages that don't already exist in extras-devel. I think this would be rad. You should probably also exclude packages that already exist in the SSU and SDK repositories, just to avoid confusion. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debian Etch, Rebuilt: 6,451 .debs for Maemo 5
ext Jeff Moe m...@blagblagblag.org writes: Do you have the build logs online as well? Yes, from http://obra.freemoe.org/freemoe-etch/3/3dchess/root.log to http://obra.freemoe.org/freemoe-etch/z/zziplib/build.log Great! * Depends: are ok? Just because the Build-Depends: were there doesn't mean the Depends: are there. Yes. Would be good to compile a list of such missing Depends and maybe put some extra effort into making them build, too. There will be cyclic build dependencies, though, and things get interesting then. ___ 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?
ext Aldon Hynes aldon.hy...@orient-lodge.com writes: While there are some in the free software movement that hold to various definitions of what 'free' means as well as many different licenses that people argue about, to most people buying cellphones, those discussions are meaningless. In the context of this discussion, however, people know what they mean with free. You are not contributing by bringing up the age old confusion that others create about the term. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build Server Configuration
ext Jeremiah Foster jerem...@jeremiahfoster.com writes: Why do you need scratchbox to build debs? You need it to build debs for Maemo, unfortunately. The Maemo SDK does not run anywhere else than in Scratchbox. (For example, last I looked, the Maemo SDK relies on /scratchbox/tools/bin/find being there. There is no /usr/bin/find.) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Where is the contextd?
ext Zhang, Xing Z xing.z.zh...@intel.com writes: Is there any online documentation for Contextkit? Yes, we have the -doc packages unpackaged here: http://zagadka.vm.bytemark.co.uk/docboy/contextkit-doc/html/context-intro.html I apologize for my old Fedora, it lacks so many tools to build the in-source documentation (I don't know what is Dot drawing tool, I google it but get nothing). It's part of graphviz, and even older than your Fedora. :) And could you point out a tool which works as subscriber? I just want to test a provider. You can use the context-commander to test providers and subscribers: http://maemo.gitorious.org/maemo-af/context-commander There are also hello-world class example programs: http://maemo.gitorious.org/maemo-af/contextkit-subscriber-example http://maemo.gitorious.org/maemo-af/contextkit-provider-example ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Where is the contextd?
ext Zhang, Xing Z xing.z.zh...@intel.com writes: Hi Marius: I met below errors when compiling context-commander: dottreemodel.cpp:28:22: error: duration.h: No such file or directory dottreemodel.cpp:29:25: error: contextjson.h: No such file or directory These headers are in libcontextsubscriber. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
Kojo Tero (Nokia-D/Helsinki) tero.k...@nokia.com writes: Marius, I want root access on all your machines. I want it, now! :) Dude, after all this, I wouldn't even let you ride my bicycle. Also Marius, would you watch your language. Calling people names is rude. It gives a bad picture of your character, and is against netiquette. You should know better, it's not a kindergarten. Heh, are you referring to me saying many of our paid sysapes? That wasn't directed at anyone in particular, it was kind of a heat seeking missile. In any case, apologies if I hurt some people's feelings. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
Kojo Tero (Nokia-D/Helsinki) tero.k...@nokia.com writes: Large publicly listed companies have very strict rules when using money. There's even a law about it in the USA (http://en.wikipedia.org/wiki/Sarbanes_oxley) That has the implication that a listed company cannot buy from wherever, and that limits the choices considerably. Uhh, that doesn't bode well for ovi.com... :-) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Where is the contextd?
ext Zhang, Xing Z xing.z.zh...@intel.com writes: I am trying to play contextkit. The README file told me there should be a contextd(context daemon). Unfortunately, I can't find it in my source directory after build while I can see libcontextprovider.so.0.0.0 and libcontextsubscriber.so.0.0.0. Anyone knows where the contextd resides or it has another name? thank you. It's in the contextkit-maemo repository: http://maemo.gitorious.org/maemo-af/contextkit-maemo The contextd daemon is pretty Maemo specific, while the rest of the ContextKit shouldn't be. I have updated the README. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-devel] List emails subject prefix
ext Marcin Juszkiewicz mar...@juszkiewicz.com.pl writes: But I also read mails on N900 and Modest do not have such one ;( Are you saying you can not get yourself a proper email client? :) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
ext Graham Cobb g+...@cobb.uk.net writes: It is still my view that, if at all possible, applications should install on the initial release. Yes, this is very important. [ Still, it is also important to give good guidance to the user when it does have in fact to update the OS before he can install a certain application. But let's concentrate on your point here. ] You propose to achieve this by building (most) applications in the SDK that has been released with the initial release. This means that the build environment for (the majority of) applications will not be updated and we have no good way to fix bugs in it. This is a very high price to pay, IMO. The build environment will not be updated since the SDK releases done by Nokia are not able to produce applications that can be installed on older OS releases. And this is the real problem that we should attack: We (Nokia) needs to make SDK releases that produce applications that can be installed on older OS releases, unless they really do in fact need features that are only available in a newer OS release. This is the next step in Maemo's path to distribution enlightenment. Maybe it comes a bit late, but better late than never. The primary mechanism at work is Debian's 'shlibdeps' machinery. This machinery determines how the dependencies look that applications acquire at build time. We (Nokia) need to master this machinery much better than we do now. man dpkg-shlibdeps man dh_makeshlibs man dh_shlibdeps First, we can analyze the package.shlibs files in a SDK release to see building against which packages will require newer OS releases than the previous SDK release. If we are not happy with what we find, we can reject that SDK release. (Of course, this analysis should be done continously and not only once we have a release.) Second, we need to seriously work towards producing 'better' package.shlibs files, and to start using package.symbols files. Ideally, there shouldn't be any 'accidental' dependencies: If a executable in package-A links against a library in package-b, then package-a should depend on package-b (= VER) where VER is the lowest version of package-b that has all the symbols that package-a actually uses. This can be achieved with package.symbols files. man dpkg-gensymbols A compromise to using dpkg-gensymbols is to manually pass a good value to the -V option of dh_makeshlibs. This is the least we should aim for. All we need is an exception process for the very, very few apps which want to make use of the few new features introduced in the new releases. That is why I proposed the alternate builder queues which will cause the builder to use a later SDK. Any application built using one of the alternate queues will not install on all versions of Fremantle so using it is discouraged unless it is necessary. This will work, but it would be a testament to our (Nokias) incompetence of making good SDK releases. I hope we can avoid that. But it is certainly an option, if only temporarily. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
ext Graham Cobb g+...@cobb.uk.net writes: I *think* that, here in Maemo, we are trying to create a model with different goals from any of the other distributions, so our decisions may also be different, but I certainly want us to learn from other experience. I wouldn't put it as different goals, but with additional goals. One additonal goal of Maemo is to support 3rd party development in a better integrated way than Debian and other distributions do. Debian does of course support 3rd party developers: they stick to standards like FHS and LSB and they are generally not screwing over 3rd party applications (unlike the Linux kernel does with out-of-tree drivers, for example). Maemo tries to integrate '3rd party' developers more tightly into the distribution, by offering processes and infrastructure for them (maemo.org) and platform support (Appmanager pointing to maemo.org by default, more user friendly view of packages). But that's an addition to what Debian and other Linux distributions do, and not in conflict with it. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
ext Dave Neary dne...@maemo.org writes: I guess that the problem is that you demand rather than request. Dave, for effs sake, Joe is not trying to get something for him and he is not getting angry because he isn't getting it. Joe is pointing out opportunities for Maemo's improvement and he is getting irritated because we are not honest with ourselves and try to dismiss that there are problems to begin with[1]. It is very easy for Joe to just go away or to shut up, without any loss to him. We should be happy that he doesn't, it would be a loss for us. He can do good for maemo.org, and I wouldn't be surprised if he can do more good than many of our paid sysapes. Get him root access already. [1] And no, we are working hard to improving things is not good enough. Even the way we implement improvements needs to be improved. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
Marius Vollmer marius.voll...@nokia.com writes: Dave, for effs sake, Joe ^^^ It's Jeff of course. Sorry, I blame the lack of coffee. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: LCA: How to destroy your community
ext Jeff Moe m...@blagblagblag.org writes: Here is a good article in LWN about a presentation by Josh Berkus. How many of these points apply to Nokia? I'm afraid way too many. Maybe, but I find it also interesting how many points do _not_ apply. Maemo - it could be so much worse :-) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
ext Dave Neary dne...@maemo.org writes: You could accomplish a lot more by rattling fewer cages. You've known this community for 50 days. It is important to listen to newcomers. They can provide much needed reality checks and maybe keep you from staring at your own naval too much. While it is certainly nice to get these reality checks delivered in nice ways, we should listen to what is being said even if we don't like the tone. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder/SDK dpkg too old to support triggers
ext Andrew Flegg and...@bleb.org writes: The versions of dpkg in play, according to `dpkg --version': Native Ubuntu (Jaunty) 1.14.24ubuntu1 N900 (2.2009.51-1) 1.14.25 Scratchbox (Fremantle rootstrap) 1.13.25 The downlevel version in the SDK means you can't build packages which use the features of dpkg on the device. It is actually debhelper that is too old in the Maemo SDK, not dpkg. As you Faheem has shown, you can work around that quite easily. So, two questions: 1) Is there a reason for the older dpkg in the SDK? We never thought that we might need to update build tools in the SDK. It's a big surprise that this is necessary. (Joking, of course. I'd say the old tools in the SDK is just another example of how all love is lost when big corporations try to do open source.) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder/SDK dpkg too old to support triggers
ext Marcin Juszkiewicz mar...@juszkiewicz.com.pl writes: Dnia sobota, 16 stycznia 2010 o 10:05:28 Andrew Flegg napisał(a): The versions of dpkg in play, according to `dpkg --version': Native Ubuntu (Jaunty) 1.14.24ubuntu1 N900 (2.2009.51-1) 1.14.25 Scratchbox (Fremantle rootstrap) 1.13.25 [...] Simple 'apt-get update/upgrade' will give dpkg 1.14.25 in any Fremantle SDK. Yeah, but the version that matters is the one in the debian-etch devkit, not the one in the rootstrap. Run dpkg --version, and you will be surprised... :-) @ apt-cache policy dpkg dpkg: Installed: 1.14.25maemo2+0m5 @ dpkg --version Debian `dpkg' package management program version 1.13.25 (i386). @ which dpkg /scratchbox/devkits/debian-etch/bin/dpkg @ /usr/bin/dpkg --version Debian `dpkg' package management program version 1.13.25 (i386). @ SBOX_REDIRECT_TO_DIRS= /usr/bin/dpkg --version Debian `dpkg' package management program version 1.14.25 (i386). Never mind how badly nokia Maemo team broke Debian which was used as base long time ago methods from it should work. Well, thank god we didn't break Debian. :-) But, yeah, Maemo is in a very bad shape, distribution wise. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Extras-devel repository index out of control?
Hi, even I have noticed now that apt uses a lot more space than it used to. One reason is that the package index files in the repository contain entries for multiple versions of a package. This increases the size of what apt has to download, process, and store significantly, and for no real benefit. For example, http://repository.maemo.org/extras-devel/dists/fremantle/free/binary-armel/Packages is about 13M, and has 25 versions of conboy-midgard listed in it, and 29 versions of gpxview[1]. I don't know if there is a mechanism in place to control this growth, but there should be. I think it would be fine to retain only the most recent version for each package in extras-devel. We can still keep older versions in the pool, and we can even make a extras-history repository that indexes all these old versions. But for extras-devel itself, I think having only one version is best. [1] But only 5 versions of mussorgsky. Ivan, release early, release often! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Optification creates link-loop
ext Cornelius Hald h...@icandy.de writes: I´ll just hope that Marius finds some time to fix this and until then I´ll turn it off again. Yep, I will find time. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Command line applications and Extras
ext Valerio Valerio vdv...@gmail.com writes: Are the responsible(s) for the Application Manager willing to implement this change and ship it in a firmware update ? (pr1.2, pr1.3) I think it is now high time to move the category definitions out of ham and somehow get them from the repositories themselves. I think the QA process for Maemo Extras is now strong enough to make sure that only packages with 'good' categories reach the end user. In other words, I think that the category mess can now be sorted out in the repository itself and the Application manager can again be permissive. Maybe this isn't true enough yet, and we still want HAM to police the categories. In any case, we need to read information about categories from the repositories: translations, icons, other things. HAM could read this extra configuration from the repository itself (i.e., not from a package in that repository), in the same way it reads the Release and Packages files. A Release could have a pointer to repository meta data files that contain additional information. This would require changes to the repository maintainence machine on maemo.org, and thus it would maybe be better to get the repository meta data from a package in the repository, using a canonical name made from the information in Release. (Have to think about how to do that concretely.) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: debian/optify not sufficient
ext Till Harbaum / Lists li...@harbaum.org writes: i just added a debian/optify file containing nothing but the word auto to Maep 1.1. Unfortunately the resulting deb package still has the binary in /usr/bin Why? Could you show a complete transcript of the build? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: how to show installed application icon on the App manager's Uninstall menu
ext ibrahim ibrahim@asgatech.com writes: I wonder if an application package was installed from command-line using dpkg -i package_name.deb can it -at least- be uninstalled using the app manager ?? does it have a chance to appear on Hildon application Manager's Uninstall list ?? Yes. If it is possible, how to do that? the packages installed by dpkg -i can be seen and removed by the apt-get command (apt-get remove installed_paclkge_name manages to find and uninstalls it ). So, why the app manager can't see them? Isn't it a GUI for apt ? or it uses another method to install/update/remove maemo packages ? The Application manager only shows packages in the user section. They need to have a field like this: Section: user/category in their control file. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Auto builder - Maemo-Optify
ext Andrew Flegg and...@bleb.org writes:
Also, it'd be useful to have confirmation from Marius if the
heuristics described here regarding Python apps have been implemented
in mode auto:
http://lists.maemo.org/pipermail/maemo-developers/2009-December/022807.html
Not as written. I think I have the framework in place now, and we only
need to find a working implementation of the is_python_package function.
http://maemo.gitorious.org/maemo-af/maemo-optify
http://maemo.gitorious.org/maemo-af/maemo-optify/blobs/master/maemo-optify-deb#line36
Currently, is_python_package looks like this:
sub is_python_package {
my ($dir) = @_;
# XXX - some input from Pythonistas is required here.
return (-d $dir/usr/lib/python2.5
|| -d $dir/usr/share/pyshared
|| -d $dir/usr/share/pyshared-data
|| -d $dir/usr/lib/pyshared
|| -d $dir/usr/share/python-support
|| -d $dir/usr/lib/python-support);
}
I will change that to something closer to what has actually been
proposed. Concrete patches are most welcome, of course!
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Automatic optification
ext Graham Cobb g+...@cobb.uk.net writes: I still have to do something about the Python optification. I will do that in the next few days. Thanks. We really need this in order to turn on optification by default. I have some first version of a test that tries to identify Python packages in the maemo-optify Git repo. It might just work. My current idea is that we will have a rule that takes in ratios: You need to have 20 times as many bytes (uncompressed) on the eMMC than on the OneNAND. The idea with this is that when all packages conform to this, your will most probably run out of eMMC before you run out of OneNAND. Can you explain that in more detail? Do you mean that you will optify (move) smaller and smaller files until you get to the right ratio and then stop? Yes, exactly. What if you can't get to the right ratio -- is that a failure? No, it would just make a package that is not as optified as one would hope. It would be up to the QA process to decide how to proceed with such a package. Are you still planning to allow the developer to override decisions? Yes. I should probably start with that, so that we can more easily control the heuristic from the outside. Do we actually need that level of complexity? With enough control over optification, hopefully not. I really don't like the idea of the optification changing between releases just because one file has changed size -- for example, I wouldn't want the developer to find that one of their files (e.g. a binary) has suddenly been moved because a different file (e.g. a text file) has changed size. That is asking for creating unexpected bugs. Yes, good point. But this can happen with any heuristic. Now, if a file gets bigger than 2k, it will suddenly be optified. That might be just as unexpected. I would prefer to keep the algorithm the same as we have now, as we have got some experience with that, and turn on automatic optification with that algorithm. Yes, I agree. So any change I'll make to the algorithm from now on will be off by default. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
ext Anderson Lizardo anderson.liza...@openbossa.org writes: Well, the direct dependency check wouldn't do anything useful anymore, or would it? (I.e., has-dependency || pymaemo-optify-is-installed == pymaemo-optify-is-installed.) Yes, having pymaemo-optify installed after .deb's have been created would be a indication of that package depending (directly or indirectly) on some Python package during build. That is true on the buildbot, but not on people's machines. The buildbot has close to the minimal amount of packages installed for any given build, but people's machines have a lot unrelated packages installed, usually. So I don't think we should look into the build environment, we should only look into the source tree or the packages that have been built. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
ext Andrew Flegg and...@bleb.org writes: On Sun, Jan 3, 2010 at 10:56, Matan Ziv-Av ma...@svgalib.org wrote: What do you mean optify is the default? optification is a temporary hack, and it is being replaced by a real solution as soon as possible. I'll put money on it being a temporary hack for the lifetime of Fremantle; Yes. I would consider it a complete disaster if Maemo 6 requires optification as well. It would be awesome to get rid of optification already during Maemo 5, but that is probably not feasible. The plan for Maemo 6 is to put everything on the eMMC by default. It has not been implemented yet, and there is thus not much experience with running the whole OS from the big eMMC. There might still be some surprises caused by the performance differences between ext3 and ubifs, or between the OneNAND and the eMMC. But I don't expect these surprises to topple the whole plan of putting everything on the eMMC by default. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
ext Frantisek Dufka duf...@seznam.cz writes: It has not been implemented yet, and there is thus not much experience with running the whole OS from the big eMMC. As for getting experience - it is easy to gain it by cloning any current OS version to card ;-) Yes, we just haven't done that internally in any official way... There might still be some surprises caused by the performance differences between ext3 and ubifs, or between the OneNAND and the eMMC. For previous devices it felt faster when booted from card except some corner cases (frequent fsyncs in sqlite causing metalayer-crawler to take ages). Yes, fsyncs on ext3 (in Tracker and elsewhere) is what I am mostly worried about right now. People here have brought up the idea to have a small partition on the OneNAND specifically for database journals. Maybe mounted on /var/journals? And BTW when OneNAND is free, in theory it could be used for swap (over ubi) causing less writes to eMMC when system is out of memory and already slow. Yes, that's the plan. (Don't know the details of how swap will be put on a mtd, though, but I am confident that our kernel guys will dtrt.) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
ext Ed Bartosh bart...@gmail.com writes: I'll definitely find a time to do whatever is needed. Moreover, I was asking couple of times already if it's time to enable optification by default in autobuilder. I was given an answer that some testing is still needed. I think Marius should know the latest status. I still have to do something about the Python optification. I will do that in the next few days. The 'something' will likely be some way to detect the relevant packages and to stop optifying them in auto mode. (Indirect dependencies are a bit expensive to follow, so my current idea is that I go with a list of direct dependencies instead.) Also, I want to improve the heuristic and the official rules for optification together that using maemo-optify will automatically make your package conform to the rules. In other words, I want to avoid the situation where you need to do more than using maemo-optify to satisfy the QA criteria about optification. My current idea is that we will have a rule that takes in ratios: You need to have 20 times as many bytes (uncompressed) on the eMMC than on the OneNAND. The idea with this is that when all packages conform to this, your will most probably run out of eMMC before you run out of OneNAND. I'll try to do that in the next few days as well. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
ext Anderson Lizardo anderson.liza...@openbossa.org writes: Is maemo-optify-deb run on autobuilder inside the scratchbox target and after all dependencies have been installed? Yes. It is run after the package archives have been built and after pymaemo-optify has done its thing. So maybe it is best just to look for the effect that pymaemo-optify has. Maybe pymaemo-optify could even just echo none debian/optify... I'll have to have a closer look at how pymaemo-optify actually works... (We should also think about folding pymaemo-optify into maemo-optify completely, but that can be done later as well.) If so, checking whether pymaemo-optify is installed on the scratchbox target would be one heuristic to detect indirect dependencies, Yeah, I was thinking of that, too... Maybe it is indeed good enough. This together with the direct dependency check (i.e. looking by pymaemo-optify or python or python2.5 on Depends) would make a good heuristic (in my opinion). Well, the direct dependency check wouldn't do anything useful anymore, or would it? (I.e., has-dependency || pymaemo-optify-is-installed == pymaemo-optify-is-installed.) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
Marius Vollmer marius.voll...@nokia.com writes: ext Anderson Lizardo anderson.liza...@openbossa.org writes: Is maemo-optify-deb run on autobuilder inside the scratchbox target and after all dependencies have been installed? Yes. It is run after the package archives have been built and after pymaemo-optify has done its thing. So maybe it is best just to look for the effect that pymaemo-optify has. Oi wei, sorry for the brain fart. I only now realize that pymaemo-optify works at run-time, not at build time... (We should also think about folding pymaemo-optify into maemo-optify completely, but that can be done later as well.) So forget about this, obviously. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: /usr/local
ext Thomas Tanner tan...@gmx.de writes: /usr/local seems to be in all search paths You might be right, but my gut doesn't trust this, not with a system with as little respect to tradition as Maemo has (i.e., our own new components will in all likelyhood get this spectacularily wrong). Also, putting stuff into /usr/local is still non-standard, and this whole sorry episode is meant to be very temporary. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo AutoBuilder - maemo-optify issue [broken]
ext Nathan Anderson nat...@andersonsplace.net writes: It appears that maemo-optify doesn't work (not sure where the --auto came from) doesn't work on the diablo builder. Looks like maemo-optify in Diablo is too old. It shouldn't be there at all, I think, but it's better to keep it up-to-date, so I have updated it. If we ever change the default for --auto, we should be careful to do it only for Fremantle, somehow. I'll put some comments into the code, and maybe a skeleton to make it easy to do the right thing when the time comes. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
ext Attila Csipa ma...@csipa.in.rs writes: A broader question is if the 500K as a *number* should be part of the blocker paragraph. [...] I think the only sane thing to do is to look at the ratio of files in /opt to those not in /opt, and require that ratio to be at least the same as the ratio of the space in /opt to the one in /. Maemo-optify could be changed to move as many files into /opt as needed to meet this requirement, starting from the biggest. It's on my todo list... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
ext Till Harbaum / Lists li...@harbaum.org writes: it's likely wait too late for such a question, but why doesn't just /opt/bin, /opt/share etc exist with the system looking into those paths as well? My gut feeling is that this is not feasible in the short term, and not good enough for the long term. It is not feasible in the short term since it likely requires many iterations of the OS itself in order to get this to work reasonably well, and OS iterations are unfortunately just too damn slow. That's my feeling at least, and I was looking for a 'solution' that didn't require changes to the OS itself. (Incidentally, we shouldn't have made the /opt - /home/opt symlink either, we should just have 'homeified' packages to /home/maemo. The symlink has caused more than its share of problems...) Now, in the long run, I hope we do not have to do any of this. The rootfs should just be large enough, either by putting it on a single big partition, or by combining multiple partitions transparently with some kind of unionfs, lvm, or by just mounting /usr from a second partition. This allows us to stay compatible with the rest of the world, and is what common sense dictates. (The current plan is to have one big partition for /, but only for Harmattan.) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debhelper 7
ext Yves-Alexis Perez cor...@debian.org writes: 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). Does it? I have to try harder, then. I always need to put things like this into my debian/rules to get non-empty -dbg packages: override_dh_strip: dh_strip -plibgq-gconf0 --dbg-package=libgq-gconf0-dbg dh_strip Time to have a look at the debhelper docs again... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debhelper 7
Denis-Courmont Remi (Nokia-D/Helsinki) remi.denis-courm...@nokia.com writes: 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? It also takes care of building. Check the documentation of the Build system options in man debhelper and look into /usr/share/perl5/Debian/Debhelper/Buildsystem. The dh program itself is a simple sequencer that runs a score of dh_* utilities in the right order, including the new dh_auto_configure, dh_auto_build, and dh_auto_install. These dh_auto_* utiltities can recognize a number of buildsystems, like autotools, Makefile.PL, setup.py, etc. AFAICT, if you really want short and implicit rules, you could use CDBS. That works fine with any debhelper from version 4 and up. It's a matter of taste, I guess. I personally find cdbs impenetrable, what with the million variables that you need to set. Debhelper really doesn't need to be wrapped up to make it easy. (The main thing missing from debhelper IMO is better support for -dbg packages.) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debhelper 7
ext Teemu Ikonen tpiko...@gmail.com writes: [...] Do you have any specific idea on why debhelper 7 does not run on Fremantle SDK (I suppose there's no need to run it on the device)? Is there any chance at all to get it working, by upgrading perl or some other magic? Yes, there is a chance, but it is not pretty. The Fremantle SDK, like all versions of the Maemo SDK, uses Scratchbox with a specific set of devkits. One of the devkits is the debian-etch one, and that devkit contains debhelper. The nature of devkits is that they shadow whatever is in the target. Thus, installing debhelper 7 in the target doesn't do anything: you will still get the debhelper from the devkit. You would either have to update the devkit itself, or somehow disable it while building your package only. You can disable the devkits with a snippet like this in debian/rules: # Sanitize build environment when running inside Scratchbox 1 ifneq (,$(wildcard /targets)) export SBOX_REDIRECT_TO_DIRS= export PATH=/scratchbox/compilers/bin:/bin:/usr/bin:/scratchbox/tools/bin endif This is a hack, and you have to assume responsibility for all the fall-out that it produces. :) That's the magic. You will likely need to update Perl as well, and then update many many Perl modules. This is what I have done for Harmattan, and now I am sitting on about 100 packages that I have updated... :-) You can also backport debhelper 7 to Perl 5.8. On balance, I think it is better to just stick to debhelper 5 in Fremantle. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
ext Anderson Lizardo anderson.liza...@openbossa.org writes: If you have plans to begin enabling auto-optification by default, please inform us here on the list so we can begin adding the debian/optify file to avoid optifying packages that were manually optified by other means (e.g. python packages). If a package already contains a /opt directory, no further optification is done by the maemo-optify tools in any case. Is that enough to protect you? We can put additional checks into maemo-optify to disable optification. I don't know enough about Python packages to suggest a good one, but maybe just looking for /usr/lib/py* in a package and stopping to do anything would work. Please suggest such an additional check if you want it and I'll add it, of course. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debhelper 7
ext Teemu Ikonen tpiko...@gmail.com writes: There is an up-to-date 'maemofied' debhelper in maemo.gitorious.org, but trying to compile it in the SDK fails miserably. The problem seems to be related to perl, which is also of similar vintage (i.e. obsolete) in the SDK. Yeah, everything in maemo-pkg is meant for Harmattan. I will update the description. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
ext Thomas Perl th.p...@gmail.com writes: The following is a rant about XB-Maemo-Upgrade-Description with some suggestions for improvement... Yeah, as soon as I 'invented' it, I could see how it is not going to work very well. I actually think it is best to ignore this field. My suggestion is to either use the Debian changelog, or if this sounds too technical for the end user, agree on some way to mark user-relevant changes in the Debian changelog (by using USER: as a prefix for a one-line summary or by having a convention of having the first entry in the Debian changelog be a user-friendly summary of all changes) and then parse the changelog and display all user-relevant changes in the AppMgr. Yes, we pretty much have to have a full list of changes and the Application manager then can display the relevant ones. The apt-listchanges program does this for Debian. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: debhelper-maemo-package-icons
ext David King dav...@openismus.com writes: You mean 48x48 pixels, right? http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging%2C_Deploying_and_Distributing#Icons Ouch, somebody needs to be tickled to death for this. (Maybe me for not catching this earlier.) Why do people think the field is named Maemo-Icon-26. Twenty-six. Rings a bell? Hmm? Like, 26x26 pixels? Could there be a connection? Anyway, trying to fix this seems to be moot. Christ. Kids these days. :-( ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
ext Ed Bartosh bart...@gmail.com writes: Maemo-optify can be invoked in a number of ways. I'll explain what happens when the modified dpkg-buildpackage calls maemo-optify-deb --auto Which is how it's used in modified dpkg-buildpackage, right? Correct. after running ./debian/rules build. - source package doesn't contain anything /opt specific, binary package doesn't contain /opt Nothing will be done because debian/optify does not exist, and the default mode is none. So, after deployment nothing should change unless developers add debian/optify to their packages, right? Correct. When autobuilder expected to start to optify packages without debian/optify in them? I don't know. We certainly need to tune the heuristic of maemo-optify first to handle Python. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Quality Assurance and Extras-testing discussion on IRC
ext Graham Cobb g+...@cobb.uk.net writes: Reporting all bugs found is great. But only dangerous issues should cause blockages. My gut feeling is that a specific bug report should always be required to block a package from entering Extras. I.e, the logic would be A package can pass into Extras when there is no critical issue reported for this package, and we have been looking hard enough to be confident that no critical issue is hiding. The enough qualification in looking hard enough could be controlled with karma, but input from the developer is always needed, if only to reset the packagw karma at the appropriate time. We can modify that to be A package can pass into Extras when it has less critical bugs reported than the version currently in Extras (or both have zero), and we have been looking hard enough to be confident that no further critical issues are hiding. This is what Debian does, and we might need to do it too, eventually, since it will happen that critical issues will be found in Extras and then we have to weigh the ciritical issues in extras-testing somehow against those in extras and decide which version we want to have in extras. We can also leave this open and require a manual decision in these cases. In any case, this puts a lot of weight on the bug reports, and there will be cases of is not a bug!, is, too, ok, is fixed, is not!, yeah, but is not critical, mofo, it is! for me! fights and we have to settle them. Maybe that is something where karma can help, too. So, hmm, I think this all means that I want developers and testers to have karma, not packages. A developer with high karma would be able to push packages through the process faster, and a high rolling tester would be able keep bugs open and classified as critical in case of disagreement. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
Voipio Riku (Nokia-D/Helsinki) riku.voi...@nokia.com writes: Every company has software testers, yet it doesn't mean they dont trust their developers :) I think there are two kinds of trust on the table here: trust in developers not to make mistakes, and trust in developers not to abuse the process malevolently. We don't need to trust developers not to make mistakes. A developer doesn't even trust himself/herself not to make mistakes, of course. But I think wa want to trust developers not to be malevolent. There will be exceptions, they will be found out and punished, the malecreants will create another account, and life goes on. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
ext Graham Cobb g+...@cobb.uk.net writes: I don't object to the autobuilder running apt-get upgrade but I would object very strongly if dpkg-buildpackage were to do an upgrade! [...] I am not sure anyone was proposing that dpkg-buildpackage would do an upgrade but wanted to point out that it can't before anyone suggested it. I was close. :) I have proposed to run apt-get install maemo-optify fmr within dpkg-buildpackage, but that is quite clearly a very gross thing to do. I have to admit that I pretty much have no dignity anymore when it comes to kicking Maemo and Scratchbitch into behaving as they should... :/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
