Re: maemo-developers Digest, Vol 59, Issue 25
We are drifing in this discussion to what it was not. It was not about package management, but about the policies of how you can provide apps to the repositories. So, let's try to keep it there. I agree with you marius that we can do the HAM part to be better. Appdownloader by itself begs me to question why not just use the browser to maemo.org downloads section, but perhaps you guys do have ideas how this can be turned out to offer something more than the browser interface (which is really nice imho). The problem of X-fade is not HAM, nor is it having central repo. It is that it's so very annoyingly hard to actually push anything to extras even once, let alone in regular intervals. Br, Urho ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Re: maemo-developers Digest, Vol 59, Issue 25
> 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. If we would actually start supporting repository delta files, then you would be at least partially right. At the moment, one of the big issues in scaling repositories is the sheer size of the databases. Sure, we do ok now, but imagine the iphone app counts. Keeping such repo in sync on the device is insane. Anyway, if I would be able to choose, I would choose central repo still for maemo 5. It scales nicely to low tens of thousands of apps. 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. Sure, but still, users only need some dozens of apps from the repo, while devices are synching repo db totally unnecessary for the other hundreds (or thousands ... or more) packages. This doesn't scale. Think of all the trees we are burning to provide energy to the communication infra! :) 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). Yeah, we should at least add the repo delta support to the repos like... immediately. 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. Sure, but many repositories allows the device to not to have to even ever care about those thousands of apps you couldn't care less about. Still, central repo is mandatory for shared libraries, but not for the apps built on top of them. Damn. I'm starting to repeat myself too much. 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). Ah, sounds like a splendid idea to me, and definitely doable with little problems. HAM performance is about 100x slower than it need be atm. 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. maemo.org/downloads would be my first pic as this discovery method. 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. If these are really interesting, let's merge to fremantle. - 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 didn't even know of this. Is it community or nokia effort? Can we get url to the code repo? > [...] 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? Well, this is a wakeup call. Either we react promptly (as in now, not in ... whenever harmattan comes out), or we will tear the house down to one degree or another. Urho __
Re: maemo-developers Digest, Vol 59, Issue 25
My 2 cents is that I find it also imbearably > - on one hand makes it easier for developers to get their updated > versions into the feeds, while > > - on the other hand make as as sure as (practibly) possible that users > (which one day will mostly not be developers) do not brick their devices > or other awkward problems that could lead them to complain quite > cluelessly and loudly at Nokia or here on the mailinglists? > > Either way it hurts. > > So we have to find a way to reduce the pain for all of us - the > developers, as Benoit is, and users. > > Maybe it could help to do a small survey about such processes for other > distributions and products? > Maemo.org is not a distribution. If it was, then developers would not have to even care about packaging, as the distro would take care of that, as well as for the QA. 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). I think there is something also badly wrong in HAM in the way of creating the data model (commits welcome), but still, the issue is the same: for a random user, there is not enough information on the ham listings to decide between several applications that provide similar functionality. However, this is available in much more rich form on the maemo.org downloads section. It makes much more sense imho to contain the Q&A in the maemo.org downloads section (have the comments, and error messages to be also linked to versions. And keep libraries in the central repo, while having an easy support for projects to setup their own repo or just to provide a deb. How I see the current status quo is that we are paranoid of ourselves. We don't trust each other enough to say that if you are a good developer (like x-fade is probably in everybodys opinion), we still demand each release that he makes to be evaluated for entry to extras. It simply makes no sense to me. I would understand it for ovi store content, but even there, the checks are simple: there is a list of issues that must be done, then the package is submitted to ovi store qa, where they test the app, check that it's optified and run a bit of tracing of the bg activities, networks use and so forth and then say that, ok, go ahead or that didn't pass because of this. I feel that currently our maemo.org testing is more paranoid, with demanding bugzilla (totally unnecessary for most of the content), nitpicking about the apps behavior (I have seen multiple thumbs down's because some tester didn't like some small feature of the app). I would not, as a community developer, put up with it. I would put up with what ovi store has in their testing model, as it is a) clear, b) there is a business reason for it for Nokia and c) I would expect to profit when the app goes to store. But for community apps, we just absolutely must relax the conditions. I would propose the following as the first step to improve the support for the community developers: if a component X has been successfully promoted to extras once, when there is an update from the same developer for this component, it will gain the access to enter extras automatically (so, developer still needs to press the magic button). This is to make it somewhat sane to do updates of the apps as well as to have testing concentrate on the new content and not have to test ukeyboard kb layouts for the 10th time in the month because some key had been moved to different position in arabic vkb (I like far fetched examples, a build fault in me). 2nd suggestion: Start promoting the downloads section more In my opinion as a community developer, I really don't have the time to even follow the testing process even once for a component that I would try to push to extras, let alone do it for every fix. This is just insane. All security comments are insane in my opinion. If some person really wants to be evil, there is nothing in our process that would block that except by accident. Ok, my 2 cents for a message that I probably should not have sent. I just really felt the pain in reading x-fades comment. I really do thing we have started to make our home our prison. I shrudder to even think what kind of winds security framework will blow our way. Yeah, this is with my community hat on - definitely not an official nokia comment. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Making extras upload on osx (missing dput and debsign binaries for osx)
Hi everybody. I'm having a slight problem of making upload to the extras repo. Steps 6,7,8 require dput and debsign, but I haven't found them for osx. Fink does not seem to have them and google doesn't seem to help me enough in locating them. Does anybody know where to get those? Kind regards, Urho Konttori ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: setting up Maemo appliance vmware
Hi, The image is packed using 7-zip. Use 7-zip program to extract the files first. Finding 7-zip should be easy using google. Then you'll end up with only the necessary few files. From there on, you'll know what to do. I wonder why normal zip was not used instead of 7-zip. Kind regards, Urho Konttori Hi maemo developers, i just finish download the maemo appliance vmware using torrent, but there are so many downloaded files, and i dont know how to make up an virtual machine from those files. does anyone having experience in using Maeme appliance vmware, let me know how to set up the virtual machine after download the files. thanks Ahhh...imagining that irresistible "new car" smell? Check out new cars at Yahoo! Autos. <http://us.rd.yahoo.com/evt=48245/*http://autos.yahoo.com/new_cars.html;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWNhcnM-> ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] OS2006 roadmap
Frantisek Dufka kirjoitti 9.1.2007 kello 21.58: [EMAIL PROTECTED] wrote: The 770 with OS2006 is still supported by Nokia. So we actually may see maintenance firmware updates (i.e. fixed bugs) for OS2006? Or even something targeted for better compatibility with OS2007? Perhaps some kind of OS2006/OS2007 combination will turn out to be practical for hacking on the 770, though again, an end-user ready release is not in the cards. Herring and Sardine (Herring is synced with OS2007/Maemo Bora) already give you Bora (and post-Bora) in the limited context of the HAF. Yes, but the question is not only about hacking, it is about end users. Can end users somehow get such system (not called 2007) so developers can ship one application (with Bora functionality) that work both on such N770 and N880? Could this be part of the .install file? One debian for 770 and one for N800. (or universal if that works for both). That way no users would ever have to know which they are installing. Also, there could be a note if no version is suitable for your device. Just a thought. May be that the .install already supports that. If that's the case, my apologies for mentioning this. Urho Konttori ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers]http://press.nokia.com:80/PR/200605/1051308_5.html
I recommend that a live cd or similiar would be launched some time in advance. That would allow developers to compile their apps in there and switch their own systems to 2.0 when 2.0 is in final state and 2006 is out. If live cd is hard to make, then a vmware image. Just my 2 cents. urho ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] swapfile is a huge improvement!
Israel Herraiz wrote: Larry Battraw wrote: hangup is having to manually remount it after a reboot, but it's worth the trouble. A GUI tool for toggling swap and mounts would sure be neat! Well, not properly a GUI tool but two menu entries for adding and removing swap, I think this could useful for you [1]. I turn on swap only when I need it (for example, I am reading a PDF, listening to MP3 and browsing the web), and turn off when I need for example to remove the card. Regards, Israel Herraiz This is just a suggestion, but could the following be safe enough for consumer grade swap use on Nokia 770: If user has swapon. User opens MMC door. System pops up a large RED GUI that states: You have swap active. Please turn off swap before removing MMC from the slot. GUI would have one large button (turn off swap). After swapoff, GUI would turn green and say, it's safe to detach MMC now. On USB cable insertion, the same GUI would popup and tell user that MMC cannot be mounted on PC until swap is off. Again, nice large button to turn swap off. When MMC inserted back from either USB connection or physically, system would check if previous state was swapon and popup a gui asking if swap should be resumed. Kind regards, Urho Konttori ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
