Mirrors
As far as I can tell, there are no mirrors of the repositories. Most large (and even small!) free software projects have complete mirrors of their archives. There are a good number of reasons: * Faster access to users that are far away on the network from the main repo. * Failover, in case something should happen to the main repository. * Distributes the load, so poor *.maemo.org doesn't get hit so hard. * Distributes the bandwidth (costs) so it doesn't all fall on Maemo's shoulders. Projects with mirrors include the kernel, kde, gnome, Fedora, Debian, etc. Basically every single distribution of note has a mirror--even the tiny ones. All that would need to be done on the *.maemo.org infrastructure side would be to set up an rsync daemon. This is like 3 lines of configuration and can literally be done in minutes by a good admin. Then someone could email a few of the big mirrors such as mirrors.kernel.org and ibiblio and voila! done. Thanks for your consideration, -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
Till, It is obvious that your angst is against my thumbs-down to your app due to my perceived understanding of optification which is at odds with yours. Nevertheless, resorting to epithets is just lame. If you have other gripes, mention specific cases where there has been gross lapse in testing that have violated the published guidelines. This will help in addressing the issues and misunderstandings. We are all in it to see maemo succeed. I take testing seriously and do this as a way of giving back to the open-source community. your desire to make fixes quickly available to the users is understandable. The way you put things, it sounds like since the first time you didn't have any problems, why should you have them now. Well, I didn't test the app the first time and even if I did, it would have gotten the same thumbs-down. If there are more users who don't care, which actually happened with libzlibrary in Fbreader, the app will end up in Extras with the opt violation. Of course, your app is not large but who knows, in the future it might be. optification is good practice. I am a developer too; but still on the maemo-developer learning curve. The experience with rating your app is not something I would consider a high-point of maemo. Mustali On Sat, Jan 2, 2010 at 7:33 PM, Till Harbaum / Lists wrote: > Hi, > > it seems that some of the extras-testing testers are not really > doing a good job. Thus it seems to happen every now and then that some > app gets a thumbs down for things it shouldn't be getting a thumbs > down for or where such a verdict is at least questionable. > > My proposal is simple: Let's setup some mailing list which > only real developers are allowed to join (may just be everybody > with a working app in any of the repositories). And once someone > thinks to be the victim of a karma-whore he may ask for help on that > list. If we have at least 10 people on such a list we can easily > override any such thumb down. In such a case the developer would > explain why he thinks the thumb down is not justified and if > enough list members agree and help out the problem will be fixed. > > Does garage allow for invitation-only mailing lists? > > What do you think? I really think it's wrong that testers can stop > bad developers, but that there's no way for developers to stop > bad testers. > > Till > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Sat, Jan 2, 2010 at 21:53, Jeff Moe wrote: > On Saturday 02 January 2010 17:54:46 Andrew Flegg wrote: >> >> At some point the default will change from 'none' to 'auto', and then >> you can opt-out by putting the single word 'none' in debian/optify. > > I hope that day comes soon with optify is the default... Can it be today? > What is needed to make that change? What's needed is more testing of it being done as part of the build process and a review of the heuristics using by maemo-optify-deb (if nothing else, any instance of pymaemo-optify in the dependency graph should prevent optification in 'auto' mode - that's the big one I think is still missing). Apart from clear communication, I imagine at some point it'll need some co-ordination between Ed, Marius, Niels and Jeremiah to try a test-run of everything currently built - perhaps into a test repo which brave volunteers can try. I think, at this point, there aren't any known blocking problems with the process so it's just taking that brave step. If everything goes well, everything gets rebuilt in extras-devel (& -testing?) with the default changed. CCing Graham as one of the council members who was in the meeting at the summit where this roadmap was laid out for his comment and ownership ;-) 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: Proposal: Sharing plugin to call command-line apps (e.g. photo sharing via SCP)
Thomas Perl wrote: > Is anyone interested in collaborating on such a plugin, or does such a > thing already exist? I've been planning to implement something like that for the scp use case but haven't had the energy yet. I'm happy to at least test it, if you get something done. Thanks, -- Tuomas ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Saturday 02 January 2010 17:23:24 Till Harbaum / Lists wrote: > Hi, > > Am Samstag 02 Januar 2010 schrieb Jeff Moe: > > Does this, perchance, have anything to do with what you are talking > > about? http://maemo.org/packages/package_instance/view/fremantle_extras- > > testing_free_armel/osm2go/0.8.1-maemo1 > > Sure > > > I must say he annoyed me to at first, but make my silly package better > > for in in the end. Seems if you just freaking optified your binary all > > these threads could die. > > Just to make this clear: I WILL do this particular optification. But this > will take some time as i am also doing other changes. And any bug i fixed > in that version is now delayed. I am annoyed by the fact that my bug fixes > are delayed for something the version already in extras also has. Where's > the advantage in delaying the update? What's the advantage in delaying the optification? It is soo easy. A whopping 4 bytes or so. It sounds like your app shouldn't have made it to extras in the first place if it wasn't optified. Just optify and let this die finally. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Saturday 02 January 2010 17:54:46 Andrew Flegg wrote: > For the record, you don't even need to do that now. All you need to do > is opt-in to the autobuilder doing optification for you, by putting > the single word 'auto' in a new file: debian/optify. > > At some point the default will change from 'none' to 'auto', and then > you can opt-out by putting the single word 'none' in debian/optify. I hope that day comes soon with optify is the default... Can it be today? What is needed to make that change? Then people will have to explain why they are opting out of optifying instead of coming up with excuses of why they won't optify. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Sat, Jan 2, 2010 at 20:47, Micke Nordin wrote: > > Am I missing something? Doesn't optification basicaly mean that > all you have to do is install a binary in your SDK and then you > have to add a single line to the rulesfile? For the record, you don't even need to do that now. All you need to do is opt-in to the autobuilder doing optification for you, by putting the single word 'auto' in a new file: debian/optify. At some point the default will change from 'none' to 'auto', and then you can opt-out by putting the single word 'none' in debian/optify. HTH, 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: Proposal: Karma-Whores protection mailing list
- Ursprungsmeddelande > > iSeems if you just freaking optified your binary all these threads > > could die. > > Just to make this clear: I WILL do this particular optification. But this will > take some time as i am also doing other changes. And any bug i fixed in that > version is now delayed. Am I missing something? Doesn't optification basicaly mean that all you have to do is install a binary in your SDK and then you have to add a single line to the rulesfile? /Micke ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
Hi, Am Samstag 02 Januar 2010 schrieb Jeff Moe: > Does this, perchance, have anything to do with what you are talking about? > http://maemo.org/packages/package_instance/view/fremantle_extras- > testing_free_armel/osm2go/0.8.1-maemo1 Sure > I must say he annoyed me to at first, but make my silly package better for in > in the end. Seems if you just freaking optified your binary all these threads > could die. Just to make this clear: I WILL do this particular optification. But this will take some time as i am also doing other changes. And any bug i fixed in that version is now delayed. I am annoyed by the fact that my bug fixes are delayed for something the version already in extras also has. Where's the advantage in delaying the update? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
Hi, Am Samstag 02 Januar 2010 schrieb Gary Birkett: > the voice of the commons is generally to be listened to. Listening to them is fine. > we put our apps into the community, > our apps are going on their devices, > why should we have more say than them? I don't propose that we need to have more to say then them. I just ask certain people to give their vote. This is how all elections work: You ask those people to vote who you think have the right understanding. I am asking developers since i trust them more than someone doing those tests to get enough karma to get the next-gen device for free. > a cabal of rebels overruling usually valid issues undermines the process for > everyone. Why are developers rebels? I am not asking those people to give a thumbs up for just everything. I ask them to reconsider and override the vote of someone who perhaps doesn't have enough knowledge of the things he's judging upon. > i have not updated any apps since finding out I also have to handle > optification and other issues. > i'm not upset at the mechanism though. I am not sure i understand that. You "gave up". Is that right? If this i fine for you: Good. But what if you could actually convince these lists members that indeed your app is a win and that e.g. in your case optification isn't useful? Why not giving you a place/group to explain your technical reasoning behind your work? > > What do you think? I really think it's wrong that testers can stop > > bad developers, but that there's no way for developers to stop > > bad testers. > > > > that sounds like a freudian slip, its right that testers can stop bad > developers. Perhaps i wasn't clear. I meant: It's good that there's a mechanism to stop bad developers. But it's bad that you can't stop bad testers. > till, I know you are miffed about this process, we all have growing pains > with the new steps, but we want all our users to have the best experience > possible So do i. Preventing bug-fixes from reaching extras due to issues the version already in extras also has is e.g. useless. You gain nothing if there already is a version in extras which has this "flaw" that's causing the update to be delayed. I am willing to learn: What's the disadvantage of uploading a new version that isn't perfect but better than the previous version? Once a program is in extras the rules what's good and bad just change. Everything better than the previous version should be "good". Or what am i missing? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Saturday 02 January 2010 16:33:56 Till Harbaum / Lists wrote: > Hi, > > it seems that some of the extras-testing testers are not really > doing a good job. Thus it seems to happen every now and then that some > app gets a thumbs down for things it shouldn't be getting a thumbs > down for or where such a verdict is at least questionable. > > My proposal is simple: Let's setup some mailing list which > only real developers are allowed to join (may just be everybody > with a working app in any of the repositories). And once someone > thinks to be the victim of a karma-whore he may ask for help on that > list. If we have at least 10 people on such a list we can easily > override any such thumb down. In such a case the developer would > explain why he thinks the thumb down is not justified and if > enough list members agree and help out the problem will be fixed. > > Does garage allow for invitation-only mailing lists? > > What do you think? I really think it's wrong that testers can stop > bad developers, but that there's no way for developers to stop > bad testers. Does this, perchance, have anything to do with what you are talking about? http://maemo.org/packages/package_instance/view/fremantle_extras- testing_free_armel/osm2go/0.8.1-maemo1 I must say he annoyed me to at first, but make my silly package better for in in the end. Seems if you just freaking optified your binary all these threads could die. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Sat, Jan 2, 2010 at 7:33 PM, Till Harbaum / Lists wrote: > Hi, > > it seems that some of the extras-testing testers are not really > doing a good job. Thus it seems to happen every now and then that some > app gets a thumbs down for things it shouldn't be getting a thumbs > down for or where such a verdict is at least questionable. > usually what you or I may think is unjustified matters to people. i > > My proposal is simple: Let's setup some mailing list which > only real developers are allowed to join (may just be everybody > with a working app in any of the repositories). And once someone > thinks to be the victim of a karma-whore he may ask for help on that > list. If we have at least 10 people on such a list we can easily > override any such thumb down. In such a case the developer would > explain why he thinks the thumb down is not justified and if > enough list members agree and help out the problem will be fixed. > the voice of the commons is generally to be listened to. we put our apps into the community, our apps are going on their devices, why should we have more say than them? a cabal of rebels overruling usually valid issues undermines the process for everyone. i have not updated any apps since finding out I also have to handle optification and other issues. i'm not upset at the mechanism though. > Does garage allow for invitation-only mailing lists? > not sure > > What do you think? I really think it's wrong that testers can stop > bad developers, but that there's no way for developers to stop > bad testers. > that sounds like a freudian slip, its right that testers can stop bad developers. > > Till > till, I know you are miffed about this process, we all have growing pains with the new steps, but we want all our users to have the best experience possible gary > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Saturday 02 January 2010 16:33:56 Till Harbaum / Lists wrote: > Hi, > > it seems that some of the extras-testing testers are not really > doing a good job. Thus it seems to happen every now and then that some > app gets a thumbs down for things it shouldn't be getting a thumbs > down for or where such a verdict is at least questionable. > > My proposal is simple: Let's setup some mailing list which > only real developers are allowed to join (may just be everybody > with a working app in any of the repositories). And once someone > thinks to be the victim of a karma-whore he may ask for help on that > list. If we have at least 10 people on such a list we can easily > override any such thumb down. In such a case the developer would > explain why he thinks the thumb down is not justified and if > enough list members agree and help out the problem will be fixed. > > Does garage allow for invitation-only mailing lists? > > What do you think? I really think it's wrong that testers can stop > bad developers, but that there's no way for developers to stop > bad testers. Closed lists are bad and only cause trouble and bad feelings. How about just bringing up particular cases to this list where you think there was an inappropriate thumbs down and it can be sorted here? It's not happening that often, is it? Any examples? -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Proposal: Karma-Whores protection mailing list
Hi, it seems that some of the extras-testing testers are not really doing a good job. Thus it seems to happen every now and then that some app gets a thumbs down for things it shouldn't be getting a thumbs down for or where such a verdict is at least questionable. My proposal is simple: Let's setup some mailing list which only real developers are allowed to join (may just be everybody with a working app in any of the repositories). And once someone thinks to be the victim of a karma-whore he may ask for help on that list. If we have at least 10 people on such a list we can easily override any such thumb down. In such a case the developer would explain why he thinks the thumb down is not justified and if enough list members agree and help out the problem will be fixed. Does garage allow for invitation-only mailing lists? What do you think? I really think it's wrong that testers can stop bad developers, but that there's no way for developers to stop bad testers. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Proposal: Sharing plugin to call command-line apps (e.g. photo sharing via SCP)
Hello! I've been thinking of creating a "SCP" sharing plugin for uploading photos to a web server, but then thought that a "generic" command-line sharing plugin would be even more universal and useful. I'm thinking of a plugin that has a single-line configuration entry that contains the command line will be called by the shell and the filename of the to-be-shared file passed in as parameter (%s), so if I want to publish photos on a server via SCP, I set up SSH public key authentication the normal way and then create a new account with the following command line: scp %s u...@server.example.org:~/photo-uploads/ The command will be called for each file that is to be shared, and the success or failure of the operation is determined by the return value of the application. The sharing framework support multiple "acounts" per "service", so our "service" (Command line) can then have multiple "accounts" (e.g. one for copying files via SCP to server A, one for copying files via FTP to server B, ...) for different purposes. Writing a shell script or utility that takes one media file to upload as argument is much easier than writing a sharing plugin for every service. Of course, it's not as user-friendly, but power users can do lots of interesting things without much effort, and we can provide "template command lines" for use by normal users (e.g. SCP, FTP, woof, copy to "manual upload queue" folder in MyDocs, ...). Is anyone interested in collaborating on such a plugin, or does such a thing already exist? Thanks, Thomas ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
sdl application hangs on exit when compiled with g++
Hi, While packaging an SDL application (for diablo) I noticed it could not cleanly exit. After a lot of trial and error a small test program showed me that when compiled with gcc it exits cleanly but when comiled with g++ it hangs when waiting for the audio thread to exit. Any clues on what I can do to fix this problem? Some things I noticed: * The SDL audio thread function does end but the pthread_join for it never ends. * When I recompile SDL to use SDL_KillThread instead of SDL_WaitThread to wait for the end of the audio thread, it does get ended but then hangs on killing the timers. -- Willem-Jan de Hoog ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Where to find sources of gtk+ 2:2.14.7-1maemo15?
El sáb, 02-01-2010 a las 07:22 +0100, Marcin Juszkiewicz escribió: > Hi > > Maemo5 repository contains sources of GTK+ 2.14.17-1maemo12 but newest > hildon-desktop requires maemo15 version (crashes with maemo12 in SDK). > > Where I can find development tree with Maemo5 gtk+? > > Regards, For others to know: https://stage.maemo.org/svn/maemo/projects/haf/trunk/gtk+/ https://stage.maemo.org/svn/maemo/projects/haf/tags/gtk+/ Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
