[GSoC 2010] Locality, locale clone
Hi, My name is Linus Wallgren. I'm interested in the locality project for GSoC 2010 and would like to introduce myself. I'm currently studying Computer Science at the Royal Institute of Technology (KTH) in Stockholm, Sweden. This is my third year and I'm currently working on my bachelor thesis and will begin my masters degree next term. I participated in GSoC last year when i wrote a command line interface for SIP-Communicator ( http://sip-communicator.org/ ) to enable users to do various tasks directly from the CLI in order to make it easier for scripts to interface with SIP-communicator. For example could it be used for automatic calling or sending of messages. The first time I heard of Maemo was when the hype around the N900 started and I knew I had found what I for so long had been looking for as soon as I got in contact with the community around Maemo and saw how everything was handled and how helpful and knowledgeable everyone was. I feel that the locality project will be a great help to many users and there are a wide variety of applications for it. I have been thinking about developing an application such as this by myself but have as of yet not had the time to get started. Example use-cases range from changing telepathy status depending on location to alter the frequency of mail updates depending on battery status and connection type. The fact that the project involves working with so many parts of the system means that I have a lot of opportunities to learn. The project would also give me great insight into how development on Maemo works. I go under the nick ecksun both in the forums and on freenode, feel free to contact me :) Best regards Linus Wallgren ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
refinding the syncing question
I am looking to develop a program that will do this in PySide, where can I find docs about the API and the requisites to do so? program == "periodical sync between Maemo and Symbian" Sivan ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Best practices to sync between N900 and N97 Mini.
Hi lists, I am trying to find the best way to sync between the two devices on a periodical term and document it on the wiki or in my Forum Nokia Blog. What is the official or preferred way to do this sort of task? Sivan ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N900 / Media Player / Random play really random?
El jue, 25-03-2010 a las 15:27 -0400, ianaré sévi escribió: > > But one way to avoid it would be to keep a record of which songs were > played _between_ sessions, and not play them again untill all songs > are played. Just don't push "shuffle all songs" and go directly to the playlist view. Claudio ps: isn't this a topic for maemo-users? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N900 / Media Player / Random play really random?
On Thu, 2010-03-25 at 14:53 -0400, Ben Roe wrote: > Surely the music player should shuffle the list, not just play random > tracks from it? I don't think anyone wants random duplicates in one > session. I can't talk about Mediaplayer, but about MAFW. MAFW is actually shuffling the songs. But there's a point I have to say. Let's suppose you create a playlist with about 100 songs, puts shuffle on and start to play, and stop after 28nd clip. If you start to play again the same list from the beginning, those first 28 clips are maintained. To "clear" them shuffle should be put off and on again. If you want to see what Mediaplayer is doing, just use dbus-monitor to track the messages. J.A. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: maemo-developers Digest, Vol 59, Issue 25
> Jeremiah Foster wrote: > > This work has been largely ignored by the Nokia team running the > > repos, much to my frustration. > >>> On Mar 26, 2010, at 3:00 PM, Marius Vollmer wrote: > Yes, Nokia is good at that. ;-) > >> Jeremiah Foster wrote: > >>> Nokia is not alone. We'll soon get to see how the Intel / > >>> Nokia combo is at ignoring the community. :-) > > On Fri, Mar 26, 2010 at 11:16 AM, Dave Neary wrote: > >> How about we give MeeGo a chance to succeed before we complain > >> about its failures? > On Mar 26, 2010, at 5:22 PM, Samir Faci (Dev) wrote: > > Or you know... wait for it to be released first and see what it looks > > like first hand? Just a thought.. Jeremiah Foster wrote: > I apologize - I don't mean to upset anyone. But my experience has > made me somewhat cautious. The community relationship is based on > trust. So far the MeeGo decision making process has happened > behind closed doors. This makes it very hard for me to trust that > my interests and the interests of the community are at the > forefront. Until Intel and Nokia can assure me that the community > has a voice in the MeeGo process, I'll continue to be skeptical. It often feels like I'm coming at things from a very different perspective than a lot of the people here, but I have to agree with Jeremiah. I have found the early MeeGo community extremely frustrating and have left until things settle down a bit. With that, I would like to note that there is a profound difference between an operating system and a community. We do have to wait for a while to see what the first release of the MeeGo operating system looks like, and I look forward to seeing if I can tweak my N900 to boot between Maemo, Mer, Fedora, MeeGo and maybe some Android environment. However, the MeeGo community, and perhaps most importantly the interaction between Intel and Nokia and the MeeGo community has been going on long enough for people to form impressions. These are further based on impressions of how Intel and Nokia have interacted with other communities, such as the Moblin and Maemo communities. I will note that some Moblin developers were really looking forward to MeeGo because they were hoping that Nokia would push Intel to being much more open than it has been in the past. My two cents. Aldon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-developers Digest, Vol 59, Issue 25
On Mar 26, 2010, at 5:22 PM, Samir Faci (Dev) wrote: > Or you know... wait for it to be released first and see what it looks > like first hand? Just a thought.. > > > > On Fri, Mar 26, 2010 at 11:16 AM, Dave Neary wrote: >> Hi, >> >> Jeremiah Foster wrote: >>> On Mar 26, 2010, at 3:00 PM, Marius Vollmer wrote: > This work has been largely ignored by the Nokia team running the > repos, much to my frustration. Yes, Nokia is good at that. ;-) >>> >>> Nokia is not alone. We'll soon get to see how the Intel / Nokia combo is at >>> ignoring the community. :-) >> >> How about we give MeeGo a chance to succeed before we complain about its >> failures? I apologize - I don't mean to upset anyone. But my experience has made me somewhat cautious. The community relationship is based on trust. So far the MeeGo decision making process has happened behind closed doors. This makes it very hard for me to trust that my interests and the interests of the community are at the forefront. Until Intel and Nokia can assure me that the community has a voice in the MeeGo process, I'll continue to be skeptical. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-developers Digest, Vol 59, Issue 25
Or you know... wait for it to be released first and see what it looks like first hand? Just a thought.. On Fri, Mar 26, 2010 at 11:16 AM, Dave Neary wrote: > Hi, > > Jeremiah Foster wrote: >> On Mar 26, 2010, at 3:00 PM, Marius Vollmer wrote: This work has been largely ignored by the Nokia team running the repos, much to my frustration. >>> Yes, Nokia is good at that. ;-) >> >> Nokia is not alone. We'll soon get to see how the Intel / Nokia combo is at >> ignoring the community. :-) > > How about we give MeeGo a chance to succeed before we complain about its > failures? > > Cheers, > Dave. > > -- > maemo.org docsmaster > Email: dne...@maemo.org > Jabber: bo...@jabber.org > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > -- -- Samir Faci *insert title* fortune | cowsay -f /usr/share/cows/tux.cow ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-developers Digest, Vol 59, Issue 25
Hi, Jeremiah Foster wrote: > On Mar 26, 2010, at 3:00 PM, Marius Vollmer wrote: >>> This work has been largely ignored by the Nokia team running the >>> repos, much to my frustration. >> Yes, Nokia is good at that. ;-) > > Nokia is not alone. We'll soon get to see how the Intel / Nokia combo is at > ignoring the community. :-) How about we give MeeGo a chance to succeed before we complain about its failures? Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-developers Digest, Vol 59, Issue 25
On Friday 26 March 2010 11:53:43 Attila Csipa wrote: > > 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. > > I would rather say that it's more of a formulation issue. It would be more > correct to say that a *known* or *detected* security flaw is a blocker. > Passing Extras-testing is not equivalent to a security audit - it just > means there is no glaring security issue known at the time. I can't say I > would be happy on thumbing up an application is discovered to, say, set a > default root password (I'm good at far fetched examples, too ;) Of course, there is some security benefit from the process -- some glaring security problems may be spotted. However, I agree that this is not at all a security audit. The biggest security benefit of the Extras repository is knowing that it is backed by a team who will be able to take action (such as remove the app) if an app is discovered to be a serious security issue. That is not true for extras-devel, and may not be true for 3rd party repositories. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-developers Digest, Vol 59, Issue 25
On Mar 26, 2010, at 3:00 PM, Marius Vollmer wrote: > ext Jeremiah Foster 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? Good point. I should have been clearer in contrasting the two tools - reprepro can monitoring "incoming" directories and automatically remove older versions of debs and/or source packages, keeping the repository lean and mostly free from bloat. > >> 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. ;-) Nokia is not alone. We'll soon get to see how the Intel / Nokia combo is at ignoring the community. :-) > >> 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. Heh - now I have to send patches or shut up. > And we are only in this for the short run, MeeGo > will kick this all into the bucket anyway. Indeed. >>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. I don't mean to be too critical, there has to be some line between utter chaos and someone taking responsibility. I do think that having a more team oriented server admin process would be good, but I appear to be alone in my views. Jeremiah ___ 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 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: maemo-developers Digest, Vol 59, Issue 25
On Mar 26, 2010, at 9:36 AM, Marius Vollmer wrote: > ext Urho Konttori 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. > > 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). 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 have tried to fix this by installing a set up for reprepro - a state of the art repository management system. This work has been largely ignored by the Nokia team running the repos, much to my frustration. > > 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 danger is of creating a fork of the APT process. Using upstream tools would probably be wise - your work would help everyone. > > - 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? 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. Jeremiah___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: some thread about packaging and QA
On Mar 25, 2010, at 8:52 PM, Marcin Juszkiewicz wrote: > There were plans to start using lintian from Debian for automatic checks of > Maemo packages. So far it looks like there were plans only. Lintian, with Nokia additions, is used by Nokia to do testing internally. I have set up a Maemian port of Lintian to lintian checks with Maemo specific tests. Much of lintian just does not apply to Maemo. Work has stalled since the community process never really wanted to commit time to the development of maemian. I am leaving the debmaster position in June and hope to have more time to do more maemian work, but as it stands now, there is not much being done on maemian at the moment. http://maemian.garage.maemo.org/ Jeremiah ___ 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
On Mar 26, 2010, at 8:19 AM, Matti Airas wrote: > On 25.03.2010 18:10, ext Dave Neary wrote: > >> There is an alternative - if Benoît does not want to deal with Extras, >> and others feel that the packages he was packaging are vital, someone >> else can take over as "official" packager and deal with all the stuff he >> doesn't want to. It's possible to separate packaging& development. > > Yes, I actually attempted to make this my first proposal (Benoît acting as > the upstream) but probably didn't express myself clearly enough. :-) I think you were very clear and very polite. Well done Matti, and I hope Benoit considers your offer. Jeremiah___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-developers Digest, Vol 59, Issue 25
On Thursday 25 March 2010 20:34:40 Urho Konttori wrote: > 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). Indeed, the initial effort was a lot more idealistic, but then pragmatism is catching up with us, slowly but surely :) There is already a suggestion in-place for 'fast promoting' things, but that is still not the real deal. Since there is no really universal versioning nomenclature, the 'complicated way' of doing this is to have a simple radio button element for promoting things to testing which would signalize what the new package is. If it's is just a bugfix update (an answer maybe to issues raised previously for the very same package), it would perhaps make sense to avoid resetting karma and the quarantine clock. If it's a minor update, it could mean (a possibly shorter?) quarantine, but certainly a more lax karma requirement. Or, if declared as a major update, it would be treated as such. There is a significant question of how to minimize potential abuse (whether as attempts to 'game the system' or simply because of frustration due to lack of active testers). Not presenting this as a definite solution, of course, just a general idea, the topic obviously needs further discussion. > 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. I would rather say that it's more of a formulation issue. It would be more correct to say that a *known* or *detected* security flaw is a blocker. Passing Extras-testing is not equivalent to a security audit - it just means there is no glaring security issue known at the time. I can't say I would be happy on thumbing up an application is discovered to, say, set a default root password (I'm good at far fetched examples, too ;) Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-developers Digest, Vol 59, Issue 25
2010/3/26 Urho Konttori : > [snip] > > The problem of X-fade is not HAM, [...] I believe you did this before, so I'll correct you - I think you mean Khertan :-) Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 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
Maemo.org discover client, Was: Re: Re: maemo-developers Digest, Vol 59, Issue 25
On Fri, March 26, 2010 10:57, urho.kontt...@gmail.com wrote: >> - 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? > Appdownloader is in extras-devel now. This application talks with Downloads over an API. Marius, Daniel and I had a short brainstorm session about how we could make things better than AM at the moment. We agreed to create some proof of concept based on Daniel's application. The app itself is developed here: https://garage.maemo.org/plugins/ggit/browse.php/?p=appmanager > > > Urho - Niels ___ 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.kontt...@gmail.com" writes: >> 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. Te delta files would cut down on the communication volume (which is probably significant and should be done), but the amount of data that HAM has to sift through would not decrease. > 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. Yes, and we are not even going to try. But instead of giving up on the idea of keeping packages indexed in a central place, we fix our tools to cope with the size. Roughly, everything that happens on the device must be independent of the number of available packages. >> 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. Yes, but accessing a big repository with a device is a very separate issue from maintaining the content of that big repository. I am just trying to make it clear that we can get away with fixing our devices, we do not need to give up on big repositories. >> 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. True, but now we are getting into the terminology grey area. I would prefer to call this "showing only conistent subsets of a repository to apt", not "distributing the packages over many repositories". For example, there has been the idea of splitting the big repo into smaller ones based on the first letter of the package name to get some scalability. You might get some, but in my opinion we can do much better than that. > Still, central repo is mandatory for shared libraries, but not for the apps > built on top of them. We will have decent support for installing standalone .deb files as well. >> - A maemo.org specific 'discovery client'. It interfaces with >> downloads.maemo.org over a custom protocol for browsing available >> applications. [...] > > I didn't even know of this. Is it community or nokia effort? Can we > get url to the code repo? I think it is this: https://garage.maemo.org/projects/appmanager/ https://garage.maemo.org/plugins/ggit/browse.php/?p=appmanager ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N900 / Media Player / Random play really random?
Hi, Am Donnerstag, den 25.03.2010, 18:56 +0100 schrieb Frédéric Ledain: > I am listening to random music, and I can observe that same tracks are > "often" played. Does not sound like a development issue, hence wrong mailing list. :-) Issue is known and will be fixed in the upcoming PR1.2 release: https://bugs.maemo.org/show_bug.cgi?id=7133 andre -- Andre Klapper (maemo.org bugmaster) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Builder is creating zero sized packages (Was: Re: Package import into Extras-devel from the builder stucked)
On Fri, March 26, 2010 09:17, Ed Bartosh wrote: > 2010/3/25 Henrik Hedberg : > >> Henrik Hedberg wrote: >> >> >>> It seems that packages are not imported into Extras-devel after the >>> builder has succeeded with them. Here is an example: >> >> I think I found the reason. The builder is creating empty packages. >> >> > I doubt that. > The packages themselves where fine. There was an broken package stuck in the non-free queue, which blocked the import of packages into the repository. Once packages are in the repository, the importer will fill in the correct values for the package size etc. I fixed the queue this morning, so everything should look better now. A fix has been implemented to prevent this from happening again. > >> For example, >> http://maemo.org/packages/package_instance/view/fremantle_extras-devel_f >> ree_i386/jammo/0.4.6/ >> http://maemo.org/packages/package_instance/view/fremantle_extras-devel_ >> free_armel/gltron/0.70final-9maemo9/ >> http://maemo.org/packages/package_instance/view/fremantle_extras-devel_ >> free_i386/redmond-theme/0.1/ >> > I don't see anything unusual from the builder logs: > https://garage.maemo.org/builder/fremantle/jammo_0.4.6/ > https://garage.maemo.org/builder/fremantle/gltron_0.70final-9maemo9/ > https://garage.maemo.org/builder/fremantle/redmond-theme_0.1/ > > >> I am still hoping that it is easy and quick to fix... >> >> > My guess is that something happened with the NFS share and files were > truncated somewhere between builder and repository. Try to rebuild your > packages. Most probably builds will succeed. > No need to do that, it was purely caused by a stuck import queue. > -- > BR, > Ed -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Python application packaging
Hi, Top posting here as my only comment is that you can package you Python application on device (e.g. no need for Scratchbox or rootstraps etc) just by installing our Python development environment to the device with maemo-python -device-env meta pacakge. As described here: http://maemo.org/development/documentation/programming_languages/ Maemo Python development environmet includes standard setup script to create standard installation packages (also integrated to the Maemo PluThon Eclipse IDE)... Maybe pypackager and py2deb have more functionality than standard setup script? Cheers, //Jarmo -- Date: Thu, 25 Mar 2010 17:26:08 +0200 From: Matti Airas Subject: Re: Ask for removal of some packages from Extras Fremantle repository To: maemo-developers@maemo.org On 22.03.2010 11:12, ext Beno?t HERVIER wrote: > Please, can you remove all version of the following packages from the > extras fremantle, extras-testing fremantle, and extras-devel fremantle > repository : > > [...] > - pypackager > - py2deb > [...] Hi Benoit et al, Having been preoccupied with other stuff the last few weeks, I only today came to notice the devastating incident about your packages and participation. Benoit, I respect your decisions no matter what the reasons are but am really sorry to see you go (if that's the final decision). However, as a member of the PyMaemo project I'm really worried about the fate of the pypackager and py2deb packages which allow for creating deb packages of Python programs without resorting to the use of Scratchbox. The functionality provided by these packages is quite essential to the developer story of the PyMaemo project since we don't want to force prospective PyMaemo developers to install Scratchbox and the full SDK just to have packages created. Also, from the PyMaemo project point of view, it's important to have any relevant packages within the maemo.org infrastructure (although you obviously are free not to do that yourself, this is a volunteer effort). Hence, I'd be very interested in hearing your opinions regarding these packages. Would you think it's OK if we maintained the packages on the extras.* repos? If you are still interested in developing the packages further (at least pypackager, I understood you consider py2deb as deprecated in any case), you could act as upstream to the PyMaemo-maintained packages (and still maintain your own repo if you wish). On the other hand, if you don't feel like working on them any longer, I hope it's all right for you if we just catch the ball and adopt the packages to PyMaemo proper. If that would be the case, would you rather see us do a clean fork (renaming the packages and all) or would it be OK if we just took the ownership of the current projects and carried on from there? In any case, I sincerely appreciate the contributions you've done to maemo.org and PyMaemo. Cheers, ma. -- ___ 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
ext Urho Konttori 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: Builder is creating zero sized packages (Was: Re: Package import into Extras-devel from the builder stucked)
2010/3/25 Henrik Hedberg : > Henrik Hedberg wrote: > >> It seems that packages are not imported into Extras-devel after the >> builder has succeeded with them. Here is an example: > > I think I found the reason. The builder is creating empty packages. > I doubt that. > For example, > http://maemo.org/packages/package_instance/view/fremantle_extras-devel_free_i386/jammo/0.4.6/ > http://maemo.org/packages/package_instance/view/fremantle_extras-devel_free_armel/gltron/0.70final-9maemo9/ > http://maemo.org/packages/package_instance/view/fremantle_extras-devel_free_i386/redmond-theme/0.1/ > I don't see anything unusual from the builder logs: https://garage.maemo.org/builder/fremantle/jammo_0.4.6/ https://garage.maemo.org/builder/fremantle/gltron_0.70final-9maemo9/ https://garage.maemo.org/builder/fremantle/redmond-theme_0.1/ > I am still hoping that it is easy and quick to fix... > My guess is that something happened with the NFS share and files were truncated somewhere between builder and repository. Try to rebuild your packages. Most probably builds will succeed. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GSoC 2010, eBook reader
On Thu, Mar 25, 2010 at 12:51 PM, Juhana Jauhiainen wrote: > Overall though I think it would be wise to stick to implementing a > basic UI, touch friendly navigation and good format support without > adding too much features. +1 here. Ebook reader doesn't need *that* much features (it's basically "ls" & "less" in drag), but what's there should work in a solid fashion. Good book browsing ui, TOC navigation, and read area where you can add your own annotations would be nice. It might be a good idea to research other ebook reader offerings (for other platforms) and make a list of what you think you can implement during the summer, keeping in mind that the project will continue after the summer => community can add the missing features. -- Ville M. Vainio http://tinyurl.com/vainio ___ 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
On 25.03.2010 18:10, ext Dave Neary wrote: There is an alternative - if Benoît does not want to deal with Extras, and others feel that the packages he was packaging are vital, someone else can take over as "official" packager and deal with all the stuff he doesn't want to. It's possible to separate packaging& development. Yes, I actually attempted to make this my first proposal (Benoît acting as the upstream) but probably didn't express myself clearly enough. :-) Cheers, ma. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
