Fwd: Debian derivatives census: missing SHA-1 hashes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Getting involved in the Debian Derivative Census is a great way to preserve the life of your Maemo software and potentially expand your user base. This forwarded email contains a lot more information and some requests for the use of SHA1 sums in the Maemo archive. Regards, Jeremiah Begin forwarded message: Resent-From: debian-derivati...@lists.debian.org From: Paul Wise p...@debian.org Date: August 14, 2011 23:48:09 GMT+02:00 To: debian-derivatives debian-derivati...@lists.debian.org Subject: Debian derivatives census: missing SHA-1 hashes Hi all, If you are receiving this mail that means you are participating in the Debian derivatives census[1] and that your entry has an issue. Please ensure that: 1. Your APT repositories have SHA-1 hashes for every source and binary package so we can compare with old Debian packages. 2. If you are using SHA-1 hashes in your APT repositories, please ensure that there is such a hash for every single file, especially for all the source package files. 3. SHA-256 hashes are not and will not be used by the census, but Debian strongly encourages the use of hashes stronger than SHA-1. The reason for these is that we are pursuing integration of information about packages from derivatives into Debian infrastructure and that integration will be using SHA-1 hashes to determine if packages were ever in Debian. Please note that if you are inheriting Packages or Sources files from Debian then missing SHA-1/SHA-256 hashes could be the fault of the Debian archive (http://bugs.debian.org/637563). In addition please make sure there is a contact point listed in the maintainer field of your census page. While you are editing your page, please fill in as much of the fields as you have data for. Please direct any questions you have to the derivatives list[3] or IRC channel[4]. We strongly encourage you to join both of these. 1. http://wiki.debian.org/Derivatives/Census 2. http://wiki.debian.org/Derivatives/CensusTemplate 3. http://lists.debian.org/debian-derivatives 4. irc://irc.oftc.net/debian-derivatives -- bye, pabs http://wiki.debian.org/PaulWise -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQIcBAEBAgAGBQJOSPWmAAoJEPoEpn8G2KIrtuMP/3G7pmRgnzrdyz32ibr5pEay SkdBMoZ84rbBj3qkC6yW1pxKiXVxrmx/zJ7yRi48UQbslYs7qNhL/y9Zg3skQgKA BGsEDtKXdMOn4vBUJVoMjjcFSYvAgjGRwa1Nd0JgCof9SXzpj/ZaM9ezGFSU/+h0 hCrjj4aMlxdx+ZOhFqufw1NCmO+0Czp1b3VYi8QuY6nuzZlgb1Ya3efx2z68ID/N vPHThc8x682nXak87v+gHEL+JdxMRXeYLgp8UczeZKbszhlvamw8HbWbLgv3mV2h jcH4Dzvh+DtiSnUOy5l20pvIokVM8W+sE3/gkLvHH8llrD9rzTRT4mXvgiavag6Q 942gmDt5jNywjQfDJvP3Cf5TwDOSgxhubTUOb25fQfpWePqojYW9e30buUKBSItS dlTPsYyWuG9PCr0p67RpGTJF+hLBO4qfD0oXiTrlCYt7rMRAzgcXcQ953oqbHl+f rHyTqx8b8ycCURIjHhyeG8M5Nz/XoSCbhzE0Rx9ts63qm3PDATB0svbVTTc6FNIG 1T62JhBhsbwgdjvvKutt/wN//HMPNpvPNWrkYoeUkRno3aQeNuk0x/kPvtfiqYQm 22dBkZJZy8IojcpUh4HrDuFJUXQGhJ5hDGcFq07uPFITlvxVrQUm8mCdpfizXMow arjCGFlDQeGHiYf8q2dk =VnaS -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Maemo's way forward as an Open project
Hello, I sent an email to the maemo-community list but I think it is equally l relevant here so I'm forwarding a link. The mail begins; I'd like to say to the Maemo Council, old and new, that there is an excellent way to move Maemo forward. Not just as a legacy operating system for Nokia devices, but even for newer devices. That way forward is through Debian. The mail continues here; http://lists.maemo.org/pipermail/maemo-community/2011-March/004742.html Feedback welcome! Regards, Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo's way forward as an Open project
On Mar 29, 2011, at 11:17, Hector Oron wrote: 2011/3/29 Jeremiah Foster jerem...@jeremiahfoster.com: I'd like to say to the Maemo Council, old and new, that there is an excellent way to move Maemo forward. Not just as a legacy operating system for Nokia devices, but even for newer devices. That way forward is through Debian. Excellent questions Hector. Let me see if I can answer them clearly (hopefully I'll get some help from folks on the debian-derivatives list.) * As Debian Developer how could we help on such task? If you're already a DD and have permission to upload to the repos, then perhaps adding packages that you find relevant for Debian from Maemo would be a good place to start. If these packages are already in Debian, then perhaps any relevant code and patches might get added? Maemo packages follow Debian Policy? Maemo packages should follow a fairly reasonable subset of Debian policy yes. I don't think they will necessarily be lintian clean but I think that the effort to get them there might not be so huge. Lots of packages in maemo are direct ports from Debian, so there really should be not so many packages in maemo that shouldn't build from source in Debian. * As Maemo Developer what should I do to get my packages into Debian? There are essentially two routes to submit packages to Debian if you are not already a Debian Developer with permission to upload to the Debian repos. (And there is no reason anyone on this list should not seek to become a DD if they are not already, many of your maemo skills are transferable!) The two routes are via mentors and via a packaging team. The mentors route means that you subscribe to ment...@lists.debian.org and submit your finished package from maemo to the mentors web site. Often on the mentors list someone will take a look at it and fix something if they see it as wrong or what have you, and then they can upload it to debian directly. This is an excellent route to start yourself on your way to becoming a full fledged Debian Developer. The other route is to find a packaging team, say debian-python if your software is python based, and submit your package there. Packaging teams in Debian are efficient because you can share the burden with others and there are some special tools (like PET) which help you with the work. This is also an excellent way to become a DD. There are some interesting projects like DEX which aim to reduce the patch sets from Debian to derivatives and already much work has been done in this regard with Ubuntu, maemo would be a logical candidate for this work as well. So joining the DEX project if you are a maemo dev is a really great way to get involved. http://dex.alioth.debian.org/ Hopefully that is a start. Regards, Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Help needed: packaging/distributing very small C app
On Apr 20, 2010, at 11:15 AM, David King wrote: On 2010-04-19 16:50, Dave Neary dne...@maemo.org wrote: Hi, Dave Neary wrote: I documented the packaging of a C app (using autotools for building) a while back in the wiki: http://wiki.maemo.org/Packaging#A_concrete_example_-_rot13 This starts with a tiny C program the minimum autotools stuff to build it (I don't include these - would that be useful?) and guides you through making a .deb. So I included an A to Z for this project, with the 3 files you need to create a .tar.gz using standard autotools. Let me know if it's useful. I updated this with some newer syntax and a link to some (very detailed) documentation in the wiki. I second autotools as a way to make packaging easier (once you understand them). Sorry, I discovered this thread late. But it looks like you guys have done a great job without my input. Clearly there are those who know more about packaging than I do in Maemo! :-) Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Packages interface - Warning: This package seems to be a library in a user/* section!
On Apr 12, 2010, at 8:24 PM, Niels Breet wrote: Hi Hi, Could someone explain what the packages interface considers my application as a library ? http://maemo.org/packages/package_instance/view/fremantle_extras-devel_fr ee_armel/libellule/0.0.1-3/ This is a rather lame check I added to prevent people submitting obvious libs as user applications. Starts with lib ;) heh, I don't think it is so lame, quite useful. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo Theme Maker failed to produce Debian package
On Mar 30, 2010, at 12:54 PM, Daniil Ivanov wrote: Hi all! Hi there! I'm trying to produce sample theme package using Maemo Theme Maker 1.2.9: https://garage.maemo.org/projects/thememaker/ I haven't use that tool before unfortunately, so I can't give you any advice except to contact the developer. It looks like it uses Java which is a pretty odd language to use to build debian packages seeing that debian is not necessarily consider the greatest Java platform in the world. I have a suspicion that creating a package following the wiki might be easier: http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging,_Deploying_and_Distributing There are also other tools in Maemo you might want to try; mud and py2deb, and perhaps others I am missing. Jeremiah I'm selecting backgrounds-template.png as Theme Background and nuvo-fremantle-template.png as Theme Source Image. Maemo Theme Maker produces the folder with package files and then fails with a message: Control file creation failed. =!CLEANUP START!= === cleanup: piu === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/startup-wizard === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/rtcom-messaging-ui deleted/home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/rtcom-messaging-ui/.DS_Store === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/mediaplayer deleted/home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/mediaplayer/.DS_Store === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/call-ui deleted/home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/call-ui/.DS_Store === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/gtk-2.0 deleted/home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/gtk-2.0/.DS_Store === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/images deleted/home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/images/.DS_Store === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/css deleted/home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/css/.DS_Store === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/backgrounds deleted/home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/backgrounds/.DS_Store === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/icons deleted/home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/icons/.DS_Store === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/icons/scalable deleted/home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/icons/scalable/.DS_Store === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/icons/scalable/hildon deleted/home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/icons/scalable/hildon/.DS_Store deleted recursive:/home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/__MACOSX === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/matchbox2 deleted/home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/matchbox2/.DS_Store === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/opera === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/opera/dropdown === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/opera/checkbox === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/opera/scrollbar === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/opera/active_element === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/opera/active_element_out_of_view === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/opera/push_button === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/opera/edit === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/opera/radio_button === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/opera/scrollbar_knob === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/opera/resize_corner === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/debian deleted/home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/debian/.DS_Store === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/calendar deleted/home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/calendar/.DS_Store === cleanup: /home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/matchbox deleted/home/divanov/thememaker/ThemeMaker1.2.9/piu/opt/themes/piu/matchbox/.DS_Store tar:/opt/themes/ passing: /opt/themes
Re: Maemo Theme Maker failed to produce Debian package
On Mar 30, 2010, at 2:24 PM, Daniil Ivanov wrote: Hi! Sorry, I forgot to mention pretty relevant information, that I'm searching for a one-button-press solution, which will be used on Windows by people with no Linux experience, so manual package creation is a no go solution. Then why not just submit your sources to OBS? 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 29, 2010, at 11:00 AM, Attila Csipa wrote: On Monday 29 March 2010 08:07:06 Marius Vollmer wrote: 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. Yes, we have not talked about this much but if you take a look at the gronmayer list now, you'll see that a good chunk of repos there has shut down, taking into oblivion their packages, too, and to make things worse, they nearly all miss the source section (most likely an unintentional oversight). Also a potential violation of the GPL. Also, consider that the QA/testing process we have is a 'light' (and occasionally buggy ;) version of what happens in large distros (i.e. if you have trouble complying with Maemo's requirements, Debian stable compliance is lightyears away). Indeed. The historical distros have all been through this phase of 'zillion packages from all over the net' and evolved towards centralized repositories for a reason (while keeping the *ability* to install whatever you want). I still think (and will lobby for) maemo.org supported PPAs as a recommended (not forced !) solution for testing/devel/procedural problems, instead of general repository anarchy. It might be the way to go. 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: 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: maemo-developers Digest, Vol 59, Issue 25
On Mar 26, 2010, at 9:36 AM, Marius Vollmer wrote: 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. 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: maemo-developers Digest, Vol 59, Issue 25
On Mar 26, 2010, at 3:00 PM, Marius Vollmer wrote: 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? 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
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 dne...@maemo.org 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: Ask for removal of some packages from Extras Fremantle repository
On Mar 23, 2010, at 10:35 PM, Klaus Rotter wrote: Am 22.03.2010 16:22, schrieb Graham Cobb: On Monday 22 March 2010 14:30:00 Matan Ziv-Av wrote: - You can't easily remove a package from extras-devel. (Or maybe at all? I asked for a package to be removed two weeks ago. It is still there). Contact the debmaster (Jeremiah) by direct email. It would be better if the maintainer could at least remove _old_ packages via http://maemo.org/packages/view/packagename directly. This would be the right place to add a Remove Button. I agree. Perhaps we can add this request from the community to a sprint? 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 23, 2010, at 11:24 AM, Thomas Perl wrote: 2010/3/23 Andrew Flegg and...@bleb.org: On Tue, Mar 23, 2010 at 00:20, Attila Csipa ma...@csipa.in.rs wrote: On Tuesday 23 March 2010 00:39:09 Darren Long wrote: However, in the general case where the source and the executable are not the same, I believe that maemo.org would be obliged to continue to make the source available, for at least 3 years. [...] If the source code doesn't accompany every download, then 3a doesn't apply so one of 3b or 3c must. If 3b applies, maemo.org has to continue to host the source. Why not pull the binaries and source packages from the *repositories* at the author's request and put them up in a archival directory that is not exposed via a Debian repository (and therefore not interfering with the HAM policy, etc..)? This of course can be done. I also think it the most sensible solution since it takes the packages out of the repos but preserves them physically for any eventual legal issue. Niels - do we have a repository expressly for this type of package? And if you could tell me it's location on disk I can move forward with the developer's request if we have consensus. 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
Do these packages have other packages that depend on them? Why are you guys interested in removing so many packages? Jeremiah On Mar 22, 2010, at 11:16 AM, David Hautbois wrote: Hello And please remove qypy too. David. Benoît HERVIER wrote: Hi, Please, can you remove all version of the following packages from the extras fremantle, extras-testing fremantle, and extras-devel fremantle repository : - pygtkeditor - pypackager - py2deb - pylint - vectormine - mcalendar - mtodos - mnotes - python-logilab-astng - python-logilab-common - pychecker Thanks. ___ 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: Building Maemo OS from Source.
On Mar 22, 2010, at 7:47 AM, Marius Vollmer wrote: 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. 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. 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. 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. It seems to me it is more about creating a functioning reference platform which others can take and build upon. As such it seems closer to a standard. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Building Maemo OS from Source.
On Mar 22, 2010, at 1:53 PM, Marius Vollmer wrote: 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? :-) No - surely you are right. But I think it is going to proceed from the notion that it is not quite a full distro. 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. Definitely. But the feeling I get is that they want to minimize the (perhaps inevitable) distro politics. Free Software without the Free Software process. ;) 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. Yeah, and this is where I am getting confused. Because it looks like an almost complete distro, but some of the Moblin devs seem to imply, or even say outright, that they don't want to be a full distro but rather a sort of super middleware. I don't really see powerusers caring that much about middleware. 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. I think your specific needs will determine which vendor or middleware version. If you're going to build a set-top box, take the TV MeeGo version, if you're doing IVI use MeeGo IVI, if you're doing embedded on ARM, take MeeGo ARM Vanilla. I assume that is the vision anyway. Jeremiah ___ 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)
On Mar 1, 2010, at 8:26 AM, Marius Vollmer wrote: 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. So what is the next step Lucas? Do we want to put something into the community repo to test if it works - then put in the updates on the Maemo.org servers running reprepro? Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
On Feb 16, 2010, at 9:59 AM, Jean-Christian de Rivaz wrote: Yves-Alexis Perez a écrit : Absolutely right. The success of Ubuntu and Debian have proved this. Aside of this, I am puzzled to see a project that it targeted to support both X86 and ARM processors without even considering the multiarch future. Sound crasy to me. Debian have accumulated a immense amount of knowledge on how to do this the right way and there have made many changes in the package management to handle multiarch. RPM packaging is completely outdated about this. What is at issue is developers. Intel and Maemo want to merge their projects to gain an economy of scale. Both Intel and Nokia know that they have to have a neutral third party to manage the project, otherwise devs will feel it is 'owned' by Nokia or Intel. So they turned to the Linux Foundation to host repos and such. The Linux Foundation is also deeply involved in the Linux Standards Base which decided that to be compliant with the LSB you have to support RPM. http://en.wikipedia.org/wiki/Linux_Standard_Base#Choice_of_RPM_package_format The APT system as a whole is better than RPM. One might argue that this has been proven by the runaway success of Ubuntu and other deb based distros, like Linux Mint. The wide adoption would certainly indicate that it is more user friendly especially since debian has never marketed its system nor locked in users, as Red Hat has. (Remember Red Hat's move to paid support?) Intel and Nokia do not care about the implementation of the package system, they just want revenue from app stores. The upshot from all of this is that we are stuck with RPM, there is no going back, and technical merits or even perceived technical merits do not matter. Fortunately RPM is not that hideous, at least for most use cases, and there are lots of tools like alien to convert from RPM to APT. If you as a developer are unwilling to work for these large companies, you may want to seriously consider Mer - a Maemo-based distribution designed to run on embedded devices which is much more open than MeeGo and uses APT. Jeremiah___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
On Feb 16, 2010, at 2:12 PM, Pavel Rojtberg wrote: Am 16.02.2010 10:16, schrieb Jeremiah Foster: Intel and Nokia do not care about the implementation of the package system, they just want revenue from app stores. The upshot from all of this is that we are stuck with RPM, there is no going back, and technical merits or even perceived technical merits do not matter. I would disagree that we are stuck with RPM. As Quim Gil posted today Harmattan will be already called MeeGo, but still use DEB. Frankly anything else would be lunatic of them from a technical POV. So I think if we as a community can create enough pressure for DEB, we can maybe keep it - there is one development cycle of time ;) I highly doubt the Linux Foundation is going to go back on the Linux Standards Base and use .debs, but I do like your optimism. :) My point for doing so is that switching from DEB to RPM means trashing the last 5 years of experience with this format/ the build environment, which is a kind of a pointless rewrite. Besides there is currently a large momentum behind it (Ubuntu, Chrome OS). Working against it is suicide ;) I think Chrome OS is also rpm based, and I also don't think Chrome OS gets a lot of downloads, at least compared to Ubuntu. Frankly, it is suicide not to switch to rpm. And I have much more to lose with the transition than you! :) Jeremiah (current maemo debmaster) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
On Feb 16, 2010, at 3:00 PM, Stuart Anderson wrote: On Tue, 16 Feb 2010, Jeremiah Foster wrote: I highly doubt the Linux Foundation is going to go back on the Linux Standards Base and use .debs, but I do like your optimism. :) Not that the LSB only specified the RPM package format. This was done because most distributions had a way of handling RPM packages (Debian uses alien). The LSB does NOT mandate that the distro itself has to use RPM, only that it be capable of correclty installing an application packaged with RPM. Debian is LSB compliant, so any other .deb based distro should be capable of doing the same. Wanting to be LSB conforming does not imply that a distro must be RPM based. Of course you are right. But be honest, do you really think these two companies are going to expend effort on supporting an apt based package manager? Do you think they are going to document using apt with rpms? Do you think they will advise new users and their own internal developers to use debs instead of rpm? I think bringing in a bunch of apt tools to support users who want to manage the software on their system is a worthwhile goal, and might end up improving both packaging systems, but I am a bit sanguine about official support for apt. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
On Feb 16, 2010, at 5:18 PM, Pavel Rojtberg wrote: Am 16.02.2010 14:36, schrieb Jeremiah Foster: I highly doubt the Linux Foundation is going to go back on the Linux Standards Base and use .debs, but I do like your optimism. :) actually I only care what the MeeGo version will use that is supposed to run on future Nokia handhelds. The LSB is free to recommend whatever they want - and as others pointed already out the standard does not say your distribution has to be RPM based ;) No, but the LSB said you have to support installing from rpm and building rpms is the shortest path to doing that. I think Chrome OS is also rpm based, and I also don't think Chrome OS gets a lot of downloads, at least compared to Ubuntu. Chrome OS is Ubuntu based, which is from the technical POV a very good decision - but you can expect that from Google. Wow, cool. Didn't know that. Frankly, it is suicide not to switch to rpm. please explain that. Simply because I don't think most people care - they just want it to work. And many will just go ahead and make rpms and be done with it. Meanwhile you'll have to spend time trying to convince people not to, and this seems like a waste. You're just discussing what color to paint the bike shed, and while this is a popular pastime, it is kinda unproductive. I used this phrase as switching to rpm means working against Google and Canonical, which on their own have a much better expertise than either Nokia or Intel. I think I will start a wiki page and a brainstorm vote, for keeping DEBs and to collect arguments pro/ contra. Good idea. Jeremiah___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
On Feb 16, 2010, at 5:27 PM, Thomas Tanner wrote: On 16.02.10 17:18, Pavel Rojtberg wrote: actually I only care what the MeeGo version will use that is supposed to run on future Nokia handhelds. Frankly, it is suicide not to switch to rpm. you mean all .deb based distributions are doomed to fail?? Heavens no!! I strongly feel the opposite, that rpm distros are doomed to fail. debs have wider adoption and have solved lots of problems already, rpms are becoming the corporate preference, not the developer or user preference. But for this project, MeeGo, the rpm is going to be the default format. It seems silly if you want to get your software into MeeGo to spend too much time arguing because I think people will not change - certainly not the Linux Foundation who host the repos, wiki, etc. I think I will start a wiki page and a brainstorm vote, for keeping DEBs and to collect arguments pro/ contra. according to Quim http://talk.maemo.org/showthread.php?p=529073 Harmattan is going to stay DEB based, despite being the first MeeGo implementation on Nokia devices. This is IMHO good news. Now we only need to convince them to stick to it even after Harmattan... I would _love_ to see that happen. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
MeeGo
Intel and Nokia collaboration: http://meego.com/ Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
On Feb 15, 2010, at 12:49 PM, Luca De Cicco wrote: I guess that the follow ups of this story will be very interesting. For starters, MeeGo claims to target automotive, where Intel has a very thin market share (if any). Umm, perhaps you haven't seen the GenIVI consortium? (http://genivi.org) That is an automobile consortium with lots of big players. They use Intel's Moblin. Will Intel bend to ARM for the development of MeeGo? I think they see the writing on the wall. Companies do not want a single vendor, architecture, programming language, etc. They want a healthy, diverse ecosystem. So ARM naturally has to be a part of it. It is a member of the GenIVI consortium BTW. Except for netbooks that ship Atom CPUs all the other MeeGo targets seem to be ARM devices. Any thoughts? This is an acknowledgement that the playing field is level. Let those who can develop, deploy, and market win. Those who try to lock you into their own platform (Apple, Google, Windows) won't be able to compete with thousands of developers, both paid and unpaid. Jeremiah Luca On Mon, Feb 15, 2010 at 12:32 PM, Johan Helsingius j...@julf.com wrote: Luca, So maemo-as-we-know will disappear and will reborn under the name of MeeGo? Well, disappear probably, but sounds like parts of the maemo effort will be carried over into meego. Does this mean that maemo-as-we-will-know is going to be completely opensource? Probably not. Seems the meego kernel is coming from the Intel moblin stuff, with the user interface/Qt library from Maemo. So my guess is that the UI stuff will be totally open source, but nokia-phone-specific stuff might still stay proprietary. No idea about what happens to official Nokia apps, such as Ovi maps. Julf ___ 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: Is package importing working?
On Feb 15, 2010, at 1:41 PM, Andrei Mirestean wrote: Yesterday evening it worked ok, but this morning I have the same problem. Niels apparently was working on this. Jeremiah On Mon, Feb 15, 2010 at 2:23 PM, Luca Donaggio donag...@gmail.com wrote: It seems so... I promoted a package from -devel to -testing three hours ago and the package interface is reporting its status as promoted but not imported yet. On Mon, Feb 15, 2010 at 1:20 PM, Sascha Mäkelä sascha.mak...@gmail.com wrote: Two days ago autobuilder wasn't working for me. Now that it works, package importing doesn't seem to work, as I uploaded a package some time ago and while building succeeded, it hasn't been imported yet. This is getting old... Anyway, has anybody noticed the same? Thanks, Sascha ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- Luca Donaggio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- Andrei Mirestean ___ 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: MeeGo
On Feb 15, 2010, at 12:49 PM, Luca De Cicco wrote: I guess that the follow ups of this story will be very interesting. For starters, MeeGo claims to target automotive, where Intel has a very thin market share (if any). Umm, perhaps you haven't seen the GenIVI consortium? (http://genivi.org) That is an automobile consortium with lots of big players. They use Intel's Moblin. Will Intel bend to ARM for the development of MeeGo? I think they see the writing on the wall. Companies do not want a single vendor, architecture, programming language, etc. They want a healthy, diverse ecosystem. So ARM naturally has to be a part of it. It is a member of the GenIVI consortium BTW. Except for netbooks that ship Atom CPUs all the other MeeGo targets seem to be ARM devices. Any thoughts? This is an acknowledgement that the playing field is level. Let those who can develop, deploy, and market win. Those who try to lock you into their own platform (Apple, Google, Windows) won't be able to compete with thousands of developers, both paid and unpaid. Jeremiah Luca On Mon, Feb 15, 2010 at 12:32 PM, Johan Helsingius j...@julf.com wrote: Luca, So maemo-as-we-know will disappear and will reborn under the name of MeeGo? Well, disappear probably, but sounds like parts of the maemo effort will be carried over into meego. Does this mean that maemo-as-we-will-know is going to be completely opensource? Probably not. Seems the meego kernel is coming from the Intel moblin stuff, with the user interface/Qt library from Maemo. So my guess is that the UI stuff will be totally open source, but nokia-phone-specific stuff might still stay proprietary. No idea about what happens to official Nokia apps, such as Ovi maps. Julf ___ 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: MeeGo
On Feb 15, 2010, at 4:40 PM, Thomas Tanner wrote: The problem is more complex than converting binary .debs to .rpms using a hack. alien is not a hack. It is packaged and maintained by Joey Hess who wrote debhelper. Few people know more about debian's build system than Joey. The dependencies, the build script and Debian (ucf, debconf) or Maemo (maemo-optify) specific aspects of the sources would need to be adapted as well. Backporting to Maemo5 would also be more difficult. Backporting is always going to be difficult. Who benefits more from the merger, Moblin or Maemo? Both benefit if we get the kind of scale that is imagined. We create a single platform to power many devices across the device spectrum. This is a battle for the operating system that works everywhere BUT the desktop, they already concede that Windows owns that and no one wants to fight there. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Packaging questions
On Feb 9, 2010, at 2:29 PM, Dave Neary wrote: Hi, Ajai Khattri wrote: Maybe there ought to be a link to the dh_make man page from there? Which docs were you following, and how did you get there? we're trying to make http://wiki.maemo.org/Packaging the standard quick start page, and http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging%2C_Deploying_and_Distributing and http://www.debian.org/doc/maint-guide/ the definitive more than you ever needed or wanted to know about Debian packaging, but were too afraid to ignore pages. I think it is great that we have a limited number of 'canonical' documentation so that we have a central place to send people and so that we can all work on making those central docs definitive and understandable. Is it then considered this way; 1. http://wiki.maemo.org/Packaging Quick Start 2. http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging%2C_Deploying_and_Distributing Complete Maemo Guide 3. http://www.debian.org/doc/maint-guide/ Authoritative Source If this is the way we are seeing it, I can then direct people to those documents and focus my energies there making sure they are up-to-date and complete. Jeremiah___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Packaging questions
On Feb 10, 2010, at 9:02 AM, Ajai Khattri wrote: On Tue, 9 Feb 2010, Jeremiah Foster wrote: Exactly. Thanks for pointing this out Marius. Unless I am mistaken Ajai, you were referring to building multiple *package* binaries, correct? (Not multiple application/runtime binaries.) Just to clarify with an example: when installing say, ruby, there is a main binary but also additional binaries in the package (irb, etc) - those should all be in the same package. Things like MySQL or openssh have separate client and server tool so those should be separate package. Yes, I think these are good examples. I am going to agree completely with Graham's previous email: quote If the programs are grouped together such that if the user installs one they almost certainly also want another then they should go into the same binary package (this often occurs with programs and scripts which make use of them or set them up, for example). On the other hand, if it is likely that the user may want one program without another, then they should go into different binary packages so that space is not wasted (and possible user confusion caused) by having both installed when you only want one. A good example of that is openssh-server and openssh-client: in many cases you need one or the other, not both, so they are two different binary packages built from the same source package (openssh). /quote Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Testing apps
On Feb 7, 2010, at 1:14 AM, ma...@bitblit.net wrote: Ive built a command-line app. I can bring up the Maemo UI and run the tool from Terminal just fine (from inside its source folder), however related utilities that come with the tool dont work - Im assuming I need to do a make install to fully test it. I could install it but then Im 'polluting' my dev environment with something that may not work and may be hard to remove all traces of correctly. What's a good strategy to test then? Should I make a package and use the package manager to install, test and uninstall? How do developers test apps like this? The packaging system is designed for this process. It has the added benefit of allowing you to provide a way for others to install your software. :) Using a chroot is also an easy way to do testing of your app with its environment, this can sometimes be easier than a virtual machine, but virtual machines work well too. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Packaging questions
On Feb 9, 2010, at 16:23, Marius Gedminas wrote: On Mon, Feb 08, 2010 at 12:19:10AM -0500, Ajai Khattri wrote: Im trying to create my first Maemo package and I had a few questions: 1) This package has a main binary, but also has additional binaries/scripts and library files, so do I select 'Multiple binaries' when running dh_make ? There's some confusion here that I haven't seen addressed in this thread: binary can mean a binary execution file, which is what you're thinking about, or it can mean a binary Debian package, which is what dh_make is asking about. You most likely want a single binary deb that contains all your executables. Exactly. Thanks for pointing this out Marius. Unless I am mistaken Ajai, you were referring to building multiple *package* binaries, correct? (Not multiple application/runtime binaries.) Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Ovi Store and VAT
I think this is off-topic for this list Benoit. You may want to contact OVI directly. Jeremiah On Feb 5, 2010, at 8:10 AM, Benoît HERVIER wrote: Hi, I've try to register myself on ovistore but my enterprise didn't have a vat number as it is exempted from vat (European VAT not applicable, net prices (Art. 293B CGI)). Did you think it will be availaible in short time for company where vat didn't apply or does i should stop to hope and publish my games as a shareware on non-free extras and manage paiement myself on my website ? regards, ___ 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: Packaging questions
Hi Ajai! On Feb 8, 2010, at 6:19 AM, Ajai Khattri wrote: Im trying to create my first Maemo package Awesome! :) and I had a few questions: 1) This package has a main binary, but also has additional binaries/scripts and library files, so do I select 'Multiple binaries' when running dh_make ? That depends, but for the current situation, I would say no. Firstly, creating multiple binary packages is harder than a single binary, though not by much. I recommend you start out with just a single binary if you can. 2) I got an error saying it could not find package.orig.tar.gz - what does that mean? This means you do not have an original tarball of your package that has the suffix orig.tar.gz. Take a look at the debian documentation here which should help: http://www.debian.org/doc/maint-guide/ch-first.en.html#s-dh_make 3) The summary dh_make printed said the license was 'blank' ? You have to specify the license the software is under yourself. From the man page for dh_make: OPTIONS -c, --copyright license Use license type in copyright file. license can be gpl, lgpl, artistic or bsd. If this field is not specified the copyright file has a space to fill in which sort of license is used. The field is case-insensitive so -c GPL works as well as -c gpl. You may want to review this document: http://www.debian.org/doc/maint-guide/ -- Aj. ___ 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: Debian Etch, Rebuilt: 6,451 .debs for Maemo 5
Amazing stuff Jeff - really great! On Feb 3, 2010, at 7:43 AM, Marius Vollmer wrote: 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. One thing that might be done is to compare the builds to a build in pbuilder which is a minimal set of debian tools. Also, I would like to do some testing of maemian on the built packages - just to see what sort of data there is an how to go about making maemian more friendly to developers. You've given me a login to your machine so I assume you don't mind me doing this but I thought I would ask you first. I would also like to make the maemian logs visible as well. Is that okay? Warm regards, Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maintenance of ported apps
On Feb 1, 2010, at 18:05, Pavel Rojtberg wrote: Am 01.02.2010 17:43, schrieb Bernd Stramm: This area is sort of problematic in many respects. Hijacking someone's package can suppress good work and good people. And it is quite disrespectful. what do you mean by Hijacking? Isnt this exactly the place when the package license comes in play? Remember that you have to upload your package to the repositories in debian, and even if the license is okay, you have to make it past the ftpmasters. They frown on NMUs and hijacked packages in certain circumstances. The best thing to do is to solve problems between packagers _before_ the package hits the repos. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maintenance of ported apps
On Feb 1, 2010, at 7:13 AM, Ville M. Vainio wrote: On Mon, Feb 1, 2010 at 4:57 AM, ma...@bitblit.net wrote: Im very interested in porting apps to Maemo but I have concerns about the long-term maintenance of the apps. Unfortunately the process is not codified, many assumptions are made. For example, the expectation is that if you have found an application or library you like in debian and have ported it to maemo, you will continue to take care of it as the OS and app changes. Now, there are no loss of privileges if you fail to keep the package up to date or if you go MIA, like there is in debian. It is a bit of a grey area as to what happens if someone else wants to take over your package if it is out of date. This process is somewhat informal in debian with some unwritten rules. One of the unwritten rules is that it is considered inappropriate to hijack someone else's package. I think this is a good rule and something we should consider. Porting a GTK app to Maemo requires some significant chznges, so what happens when a newer version of the GTK app appears? One reads the changelog and determines if the changes are appropriate for the maemo platform, taking the appropriate action if they are. Will in need to be ported 'again'? Essentially you should just have to apply any patches, re-build the package, and upload a diff to the autobuilder in the usual way. Should changes for Maemo be merged back upstream? If you have made local changes then yes. Otherwise you are sort of forking. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: HOWTO: Query installed application
On Jan 28, 2010, at 9:34 AM, Stefan Iwanowitsch wrote: Hi everybody, how can I obtain information about the installed applications The command 'dpkg -l' will show you all installed packages on your device. and access their icons? Icons are kept in specific directories on the device, I'll look that up. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MySQL and N800
On Jan 26, 2010, at 7:46 AM, Bjoern Ricks wrote: Sorry didn't send my answer to the list. Hi, the last weeks I tried to get a new version of mysql to extras-devel (http://repository.maemo.org/extras-devel/pool/fremantle/free/m/mysql-dfsg-5.0/). Therefore I updated the old version to the version from debian stable but I didn't tested the package carefully. At the moment the package has many disadvantages. The perl dependencies of that package are really bad, packages are to big for the N900 and mysql is installed in root dir. Now I am trying to get a new mysql version (latest of the 5.0 series) for maemo with a new package description build from scratch. Hopefully I can finish that work in the next weeks and upload a new package. Any help is appreciated ;-) What is the list of the perl dependencies? Maybe I can help you out there. Jeremiah kind gerards Bjoern 2010/1/26 Demetris demet...@ece.neu.edu Hi all, most likely I will use what Tony has ported for the N800. However, poking around the maemo repos I saw a few links to mysql server and client packages (.deb ). Does anyone know what these are and who the authors are? I tried installing them on a 5.2008 N800 but they do not install correctly: http://repository.maemo.org/extras-devel/pool/fremantle/free/m/mysql/ Thanks Demetris wrote: Hi Tony, thanks for the response - I have a feeling you may be right on this one so I will give it a shot and let you know how it works out. Either way thanks a bunch for the good help. Take care Tony Green wrote: On Friday 22 Jan 2010 17:10:47 Demetris wrote: Hi Tony, excellent and thanks for the good info. I am not sure what Java libraries I may need to port but I will give it a shot to see how it behaves. All I need is pretty much an elementary table to be accessed through a servlet I already wrote running under Java CDC on the N800. Is there a J connector available for this port I can use? You said you have been using this only for Perl-based apps so I am not sure if you ever tried any Java apps with it. Hi Demetris, I haven't tried any Java applications myself; it's a language I tried to learn many years ago and gave up because I found its OO nature too painful to use. My guess would be that it would just be a matter of picking up the necessary libraries from wherever they can be found (the MySQL website?) and putting them in the right place. If my understanding of Java is correct, then the bit-code is architecture-independent. Though my understanding may well be flawed... ___ 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 ___ 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: Build Server Configuration
On Jan 26, 2010, at 9:43 AM, Ove Kaaven wrote: Jeremiah Foster skrev: On Jan 25, 2010, at 22:27, Ed Bartosh wrote: 2010/1/25 Jeremiah Foster jerem...@jeremiahfoster.com: There are other build tools which are better documented and more flexible than sdbmock. Debian has a complete toolchain which is obviously good at building debs and is completely open and well supported. Interesting. Can you point me out to the one, which supports scratchbox? Why do you need scratchbox to build debs? Why not just use the debian toolchain? I know you don't want to learn perl, but hey, it works for debian. The Debian tools are not really designed for cross-compilation, they're meant to run inside the target environment. Yeah, this seems to be the key differentiator between Maemo's build system and Debian's. Still, there was a SoC project last year in which we could have participated to help shape the debian build process to more closely match Maemo's. No one was interested. That target environment also needs a full complement of Debian tools, including compilers. The reason it works for Debian is because they have a LARGE farm of dedicated, donated machines of various architectures: http://db.debian.org/machines.cgi I find it fascinating that a Free Software operating system, without a very formal form of governance, without any assets of its own aside from SIP, run completely by volunteers, has a larger build farm than the world's leading handset manufacturer. If someone builds a farm of Maemo devices (running on ARM, of course) that they want to dedicate to running buildds, then that might work. Otherwise, the Debian tools need to be run inside a simulated target environment, and the only simulated environment known to run Maemo (and that runs reasonably fast) is probably scratchbox... What about tools like qemu and dpkg-cross? Can't they be used to build debs without scratchbox? And my goal is not to necessarily get rid of scratchbox, but rather enable alternatives to the current build toolchain. Mer builds packages on OBS - why can't we do that for Maemo? Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build Server Configuration
On Jan 26, 2010, at 10:16 AM, Jeremiah Foster wrote: without any assets of its own aside from SIP I mean SPI of course. (Software in the Public Interest.) Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build Server Configuration
On Jan 26, 2010, at 1:05 PM, Ed Bartosh wrote: 2010/1/26 Jeremiah Foster jerem...@jeremiahfoster.com: What about tools like qemu and dpkg-cross? Can't they be used to build debs without scratchbox? And my goal is not to necessarily get rid of scratchbox, but rather enable alternatives to the current build toolchain. I still don't understand what's so bad with current toolchain and autobuilder? I'm asking not just out of curiosity, but because right now I have some free time and I'm going to spend it to improve autobuilder. My plan I was to implement the following features: - support for multiple packages builds - parallel package builds - improvements for external checks - support for building tags from garage VCS(svn and git) So, if it's not needed and community tends to switch to another build system I'd rather do something more useful. Personally I think it is highly useful the work you do. What I see as the bottleneck is the political aspect, not the technical aspect. Having alternative build environments frees us from having to rely on one autobuilder, one build machine, one process. If we could let in more community resources either through replication or distribution I think we can ease developers lives when the ISP fails to keep the autobuilder up. I realize that we again reach the limit that in order to build, we need proprietary software / tools / blobs so it will be impossible to replicate the current build toolchain, but having an independent, community managed (or assisted) build toolchain would seem to me useful and a worthy goal. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Is mauku open source, i.e free or is in non-free?
Hello, Bug #7505 asks if mauku is open or closed. According to the bug report, it looks pretty closed. https://bugs.maemo.org/show_bug.cgi?id=7505 I installed mauku from the maemo extras free repository, believing it was Free Software, but trying to figure out which license it is under, I noticed there is no license file at all, and file headers have the following message: /* Mauku 2.0 (c) Henrik Hedberg hhedb...@innologies.fi You are NOT allowed to modify or redistribute the source code. */ The debian/copyright file also says this: Mauku 2.0 is NOT open source software. You are NOT allowed to modify or redistribute the source code. I believe it should at least be moved to the non-free section, and stop claiming it ships with a free license in its download page. What should we do here? Move this to non-free? Thanks, Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Quick start packaging guide
On Jan 22, 2010, at 21:10, Dave Neary wrote: Hi all, Due to popular demand, I sat down this week with Jeremiah Foster, who explained to me the very quickest way to go about packaging an application. We didn't quite get to uploading to extras, but going from a .tar.gz to a correct .deb is there. http://wiki.maemo.org/Maemo_packaging_quick_start_guide I intend this article to be a kind of landing-point for new Maemo developers. It should contact the short path, with a bunch of shortcuts taken, and lots of links to canonical material. Thanks very much Dave! Jeremiah Email: jerem...@maemo.org Jabber: splu...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build Server Configuration
On Jan 23, 2010, at 12:07, Ed Bartosh wrote: 2010/1/23 Jeff Moe m...@blagblagblag.org: Could the configuration files of the build server and related scripts be put up on the wiki or mailed here or something? I had a build fail due to a small difference between the SDK and the buildbox. I would like to be able to have an identical setup to the build box before submitting jobs. BTW, what do you think about to prepare guide for developers for easy setup of local buld configurations identical to autobuilder ones? I can provide whatever information you need for that. Personally I think this is a great idea. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build Server Configuration
On Jan 25, 2010, at 16:22, Jeff Moe wrote: On Saturday 23 January 2010 04:07:48 Ed Bartosh wrote: 2010/1/23 Jeff Moe m...@blagblagblag.org: Could the configuration files of the build server and related scripts be put up on the wiki or mailed here or something? I had a build fail due to a small difference between the SDK and the buildbox. I would like to be able to have an identical setup to the build box before submitting jobs. It doesn't differ too much from what I showed in December[1] The only valuable difference I can see is that SDK have been changed. # Official SDK repositories: -deb http://repository.maemo.org/ fremantle/sdk free non-free -deb http://repository.maemo.org/ fremantle/tools free non-free +#deb http://stage/ fremantle/sdk free non-free +#deb http://stage/ fremantle/tools free non-free + +#revert PR1.1 because of backwards compatibility issue 2010-01-19 -Niels + +deb file:/scratchbox/packages/maemo5.0_update1_public/ fremantle/sdk free non-free +deb file:/scratchbox/packages/maemo5.0_update1_public/ fremantle/tools free non-free As you can see from the comment Niels did this change. BTW, what do you think about to prepare guide for developers for easy setup of local buld configurations identical to autobuilder ones? I can provide whatever information you need for that. Yes this would be very nice. I am starting to put all the scripts I use in a git archive on gitorious. As I set up sdbmock (starting from scratch again), I will add configs/scripts there: http://gitorious.org/freemoe/ git clone git://gitorious.org/freemoe/freemoe.git I was thinking of making a servers/ subdir and store specific configs for them in there (e.g. servers/espejo/rsync.d conf). The buildserver has been running nice and fast the last 48 hours or so--lots of packages have been pushed through. :) What distro/release is the build server running? I have generally set up Debian Lenny KVMs to use and have one set up to be used with sdbmock, but if something more recent or older is better, let me know. There are other build tools which are better documented and more flexible than sdbmock. Debian has a complete toolchain which is obviously good at building debs and is completely open and well supported. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build Server Configuration
On Jan 25, 2010, at 22:27, Ed Bartosh wrote: 2010/1/25 Jeremiah Foster jerem...@jeremiahfoster.com: There are other build tools which are better documented and more flexible than sdbmock. Debian has a complete toolchain which is obviously good at building debs and is completely open and well supported. Interesting. Can you point me out to the one, which supports scratchbox? Why do you need scratchbox to build debs? Why not just use the debian toolchain? I know you don't want to learn perl, but hey, it works for debian. http://www.debian.org/devel/buildd/ Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Engadget, developers, extras-dev and Maemo LTS
On Jan 22, 2010, at 18:54, Aldon Hynes wrote: I would respectfully suggest that engadget's view, while representing the view of the person that wrote it, is perhaps no more or less representative of the views of users than views expressed by developers on this list. Except that Endgadget has a widely viewed website. :p Developers are an important set of users. But they remain a subset. Engadget readers and another potentially important set of users. It seems to me that the balance between different catalogs, including things like extras-developer catalog helps meet some of the needs of both communities, and going forward it may make sense for other catalogs. Likewise, it may make sense, moving forward to look at supporting both a current version of maemo and a maemo LTS (long term support) version. Interesting idea - maybe Mer is that LTS version? Maybe not. Nonetheless, much food for though. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo extras repository package uploader/maintainer verification?
On Jan 22, 2010, at 11:49 AM, Eero Tamminen wrote: Hi, I was recently notified that in extras repository some package for which I've been marked as maintainer, was causing an SSU (testing) issue. However, I hadn't uploaded that package. The package was from SDK tools repository were I was the correct contact person for that package. The package in Extras had the same version, but not the same size i.e. it was modified (or at least different). What checks there are in place to verify that the package uploader and the package maintainer field (shown to people who install the packages) match? I think Niels has a check for that in the QA software he has written, in fact, I am certain of it. :) This check does not currently default to stopping the incorrect uploader / maintainer from uploading the package. It is possible to change this behavior and I think in the future this check will default to stopping package uploads that do not have the correct maintainer information. Unfortunately, people do not change the maintainer field of the packages they upload very often, this is a big problem. But stopping everyone without warning is not the solution. I think we will move towards stricter testing however in the near future, but final decisions should be discussed with Niels. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo extras repository package uploader/maintainer verification?
On Jan 22, 2010, at 2:19 PM, Ed Bartosh wrote: 2010/1/22 Andrew Flegg and...@bleb.org: On Fri, Jan 22, 2010 at 12:59, Simon Pickering s.g.picker...@bath.ac.uk wrote: I'd suggest that the autobuilder checks to see that the uploader's email address is included in one of the *Maintainer fields; but there is the slight problem of what happens when someone is uploading someone else's package (e.g. as a favour when they are away from a build machine)? There's also packages which are maintained by a team but uploaded by an individual. And there are also packages taken from Debian/Ubuntu and uploaded without any change. I don't think we should stop them from coming. It's possible to find real uploader name in autobuilder logs and might be in the /packages web UI as well. Bringing new checks like this to the system wouldn't make entrance barrier lower for newcomers. I agree. We should not allow packages uploaded to the repos without a corresponding, correct email address. Unfortunately I think a lot of packages uploaded by Nokia do not use the correct Maemo Policy recommendation, which is to change the maintainer name and email address. I wouldn't like to block the upload of libraries that are key dependencies so I don't think we should flip this switch yet - but it definitely will produce a warning. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo extras repository package uploader/maintainer verification?
On Jan 22, 2010, at 5:17 PM, Nathan Anderson wrote: Ok, I think I must be confused; I was under the impression that you leave the maintainer field alone if all you are doing it packaging it up for the maemo platform.I don't actually maintain any of the code for several of the projects that I have uploaded. You do however maintain the package. So if there are bugs it is your responsibility to push the bugs upstream if they are in the code. This is how the responsibility is divided in debian anyway, it is not explicitly laid out for Maemo but I think it ought to be self-evident. All I've done is did the work to package it up. In many cases the developer is also the packager, but when the packager is different from the developer(s) then the packager has to take on a bit of responsibility for at least packaging QA. Maintaing the code as well is usually not required, but it is considered a good thing if at least you know the programming language it is written in, etc. Am I supposed to put in the maintainer field my name, or leave it as the original team that wrote it. The only thing I change is the changelog to show that the program was packaged by me. (i.e. sword library, kernel modules) The changelog is a must, but changing the maintainer name in the debian/control file is also a must, according to maemo packaging policy. Here is the policy in pdf: WARNING PDF! https://maemo.org/forrest-images/pdf/maemo-policy.pdf Jeremiah Nathan -Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers-boun...@maemo.org] On Behalf Of Simon Pickering Sent: Friday, January 22, 2010 7:00 AM To: 'Jeremiah Foster'; maemo-developers@maemo.org Subject: RE: Maemo extras repository package uploader/maintainer verification? What checks there are in place to verify that the package uploader and the package maintainer field (shown to people who install the packages) match? ___ 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: How to destroy your community
I thought I would post a snippet from the Endgadget review that represents the view of the users of Nokia's products. This is something that Nokia bears in mind, even if we at maemo.org don't always, we tend to be self-selecting geeks. After having dug in, we're seeing glimmers of brilliance here that give us hope. Maemo 5 isn't the polished, consumer-friendly, all-encompassing solution that Palm, Google, and Apple are all selling today, but it's fairly evident that Nokia has built itself a stable, extensible platform that can reach those levels with a little tender loving care. The company's commitment to open source and the Maemo development community is commendable -- it's something that should absolutely continue -- but going forward, we'd love to see what kinds of magical things could happen if it took development to 100 percent feature completion internally with a full round of usability testing before handing it off to the eager geeks in the field. The mere thought sends shivers down our spine. The important point here is that users want _less_ developer control and _more_ Nokia control. Any smart company listens to their users and Nokia is no exception. Regards, Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
On Jan 21, 2010, at 1:35 AM, Graham Cobb wrote: On Wednesday 20 January 2010 21:50:02 Jeremiah Foster wrote: I disagree. Debian has very high quality packages and software. I don't think we are disagreeing. I am saying Debian is geared to stability and quality. I am just making the point that it achieves that by forcing things to take a long time to proceed through the QA process and severely restricting the number of packages that are accepted (I know Debian has **lots** of packages but nothing like the number of apps the iPhone has and new packages are not being added at anything like the rate any commercial AppStore accepts them -- those are the goals for us). Not sure about that, debian has maybe 27,000 packages in the stable distro, plus several thousand more in testing. Plus they manage tens of thousands more in volatile, non-free, and unstable. Not to mention backports or Ubuntu, or Mepis, etc. So I think a fairly reasonable estimate is in the neighborhood of 100,000 packages for debian and debian-like systems. Note that these packages are of diverse programming languages (iPhone apps are mostly Objective C), and that the debian packages do different things. Apple has dozens of apps that do the same thing, pdf readers, noise makers, girls-in-bikinis apps, etc. Apple is no where near as diverse and large as they market themselves to be. Besides, lots of the apps on the iPhone are built-in on the N900; skype anyone? Comparing the two is really Apples and oranges, though I understand your point; Maemo has fewer commercial apps than the iPhone and Android. Actually not true. Debian has had security for testing for about four and a half years. http://lists.debian.org/debian-devel-announce/2005/09/msg6.html Security yes. Support no. What support is missing? Debian has always relied on the community to support the OS. I think you are referring to unstable here. I run testing everywhere, even production web servers, and I have few problems. Especially compared to the Ubuntu machines I admin, or for that matter, fedora. No, I meant testing. I also use testing. But people like you, me and the members of this mailing list are not the target audience for Maemo. For example, kde is currently severely broken in testing -- it has been for many months and will continue to be for some time yet. Okay, I concede this point. I think debian should server as a model for maemo, after all, Nokia based its OS on debian. The biggest problem is Nokia's penchant for separating their releases from the community. There really should be greater cooperation between the community and Nokia, it is pretty much as simple as that. For software and tools I agree. But processes will be very different. Maemo is not aiming for a release every 18 months, Debian is. The official release time period is 24 months. That fundamental difference stops the processes being at all similar. By all means see what we can learn from Debian (and Ubuntu and Fedora and ...) but we have to acknowledge that different goals will require different processes. True enough, but greater co-operation should help facilitate whatever release goals we have. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
On Jan 21, 2010, at 1:35 AM, Graham Cobb wrote: On Wednesday 20 January 2010 21:50:02 Jeremiah Foster wrote: I disagree. Debian has very high quality packages and software. I don't think we are disagreeing. I am saying Debian is geared to stability and quality. I am just making the point that it achieves that by forcing things to take a long time to proceed through the QA process and severely restricting the number of packages that are accepted (I know Debian has **lots** of packages but nothing like the number of apps the iPhone has and new packages are not being added at anything like the rate any commercial AppStore accepts them -- those are the goals for us). Not sure about that, debian has maybe 27,000 packages in the stable distro, plus several thousand more in testing. Plus they manage tens of thousands more in volatile, non-free, and unstable. Not to mention backports or Ubuntu, or Mepis, etc. So I think a fairly reasonable estimate is in the neighborhood of 100,000 packages for debian and debian-like systems. Note that these packages are of diverse programming languages (iPhone apps are mostly Objective C), and that the debian packages do different things. Apple has dozens of apps that do the same thing, pdf readers, noise makers, girls-in-bikinis apps, etc. Apple is no where near as diverse and large as they market themselves to be. Besides, lots of the apps on the iPhone are built-in on the N900; skype anyone? Comparing the two is really Apples and oranges, though I understand your point; Maemo has fewer commercial apps than the iPhone and Android. Actually not true. Debian has had security for testing for about four and a half years. http://lists.debian.org/debian-devel-announce/2005/09/msg6.html Security yes. Support no. What support is missing? Debian has always relied on the community to support the OS. I think you are referring to unstable here. I run testing everywhere, even production web servers, and I have few problems. Especially compared to the Ubuntu machines I admin, or for that matter, fedora. No, I meant testing. I also use testing. But people like you, me and the members of this mailing list are not the target audience for Maemo. For example, kde is currently severely broken in testing -- it has been for many months and will continue to be for some time yet. Okay, I concede this point, you're right. I think debian should server as a model for maemo, after all, Nokia based its OS on debian. The biggest problem is Nokia's penchant for separating their releases from the community. There really should be greater cooperation between the community and Nokia, it is pretty much as simple as that. For software and tools I agree. But processes will be very different. Maemo is not aiming for a release every 18 months, Debian is. The official release time period is 24 months. That fundamental difference stops the processes being at all similar. By all means see what we can learn from Debian (and Ubuntu and Fedora and ...) but we have to acknowledge that different goals will require different processes. True enough, but greater co-operation should help facilitate whatever release goals we have. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
On Jan 21, 2010, at 3:54 PM, Yves-Alexis Perez wrote: On 21/01/2010 11:46, Jeremiah Foster wrote: For software and tools I agree. But processes will be very different. Maemo is not aiming for a release every 18 months, Debian is. The official release time period is 24 months. There's no “time-based” release planned at all. What's planned (and for the moment not yet done) is “time-based” freezes, which is not the same thing. Debian releases ”when it's ready” (and usually late). According to the DPL's talk last year at FOSDEM, there in fact is an informal time period between releases with a goal of 18 months and a maximum of 24 months. Both Etch and Lenny were within this time frame coming in at 22 months - so they weren't late. :-) Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Package icon within Maemo package interface
On Jan 20, 2010, at 1:19 PM, Luca Donaggio wrote: I've a (probably silly) question about package icons maemo package interface: - if I upload a new version of the same package with a different icon (urlencoded in debian/control) the corresponding package interface's instance of that package retains the old icon (it's the grsync case) - in one case (mmagnetic) there's no icon associated with that package instance Both packages' icons are correctly displayed in HAM. I've been getting a lot of questions about icons recently - not sure if it is related to a bug in the autobuilder or somewhere else, but lots of people are having problems. I don't have an answer for you immediately, I am about to do some test building (Dave Neary and I worked on a simple package yesterday, I am going to add an icon to that.) I am also going to test with MADDE as well, so in short, I hope to have more info for you soon. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
Hello, Okay, so it's knives out is it? Fine. I have flame retardant underwear. :-) I know you want things to work smoothly, we all do. Believe me, the admins are working their butts off to make it so, they work long days and have been checking in on weekends too. I still see no reason for any personal attacks, it is not necessary. I will take responsibility for part of the server move - I think we all could have done better, but this is the situation we're in, and long lectures full of conjecture won't help much. Let's summarize the constructive criticism instead. 1. Maemo.org DNS should probably be on physically separate networks, with redundant servers worldwide. DyDNS can do this cheaply, there were other suggestions as well. 2. The maemo.org repositories should be mirrored in the free software community at places like Ibiblio or similar, to provide a measure of redundancy. 3. Whatever ISP is chosen to host the site should feel like a stakeholder in the success of the maemo community. They should feel motivated for things to work 24/7. 4. The community should be allowed to help with the infrastructure. Perhaps some services should be entirely released to the community? Or maybe start using community resources like the SuSE OBS? 5. Greater communication and transparency from the maemo staff. If I have missed anything I am sure you'll let me know, in no uncertain terms. ;) And now for some return fire: patience is a virtue. This means that throwing a temper tantrum on a mailing list gets you often branded as a poisonous person, to quote from your original link. That seems really unnecessary since many of those on this list who are flaming have valid points and obviously care about the community. The valid points come across when they are delivered politely too, so I ask for that to be the default setting. We are where we are, and being impatient won't change that. Regards, Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder build error (unmet dependencies)
On Jan 20, 2010, at 20:29, Niels Breet wrote: Is this an effect of the PR 1.1 problem and I have to rebuild libIllumination, too? Yes. What you see there is that libillumination0 is built against newer gstreamer and libosso (from pr1.1) The fastest way to solve this is to submit the package again (increase revision) Have all the existing extras-* packages been (automatically) tested against the new SDK? I suppose that's the best way to make sure that they will all be installable. No, that still needs to be done. Jeremiah was working on something that created a list of affected packages. Yeah, and he is sorta struggling with that. After scanning the Packages file, and not finding much evidence of Depends: libosso1 ( 2.26) (which is the line that denotes the PR 1.1) he is sort of flummoxed as to what to do next. Trying to summon super grep powers. Will report back here and on maemork shortly. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
On Jan 20, 2010, at 17:32, Jeff Moe wrote: Can we, like with the opt problem, come to a solution with community power[tm]? For what it's worth, in the Fedora buildsystem (Koji), the buildsystem is running with the latest updates. Perhaps investigating what the various other distros do (especially Debian) and doing what they do would be a good approach (if they have mostly all settled on similar approaches). I have stated my preference for the debian build tools previously and would like to state that here again. I think a debian-based build system would be more stable than the collection of python scripts we use now and would have the extra benefit of being tested and maintained upstream. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
On Jan 20, 2010, at 18:24, Graham Cobb wrote: On Wednesday 20 January 2010 16:32:23 Jeff Moe wrote: For what it's worth, in the Fedora buildsystem (Koji), the buildsystem is running with the latest updates. Perhaps investigating what the various other distros do (especially Debian) and doing what they do would be a good approach (if they have mostly all settled on similar approaches). Jeff, thanks for the input -- we certainly need to take a look at what other projects do. I am most familiar with Debian. There the challenge is very different. Debian, like many distributions, is geared to creating periodic releases containing a consistent set of packages. It chooses to maximise stability and, to some extent, quality by sacrificing time to release and, to some extent, openness (only DD's can submit packages). I disagree. Debian has very high quality packages and software. Part of debian's success is its rigorous QA procedures. There is puiparts, lintian, and a considerable period of software traveling through testing which makes debian software high quality. Plus a good deal of packaging is done through teams so there are lots of eyes on packages. Debian also has a concept of release critical bugs and won't release until they are all gone. That is a commitment to quality that commercial operating systems cannot match - they have to meet sales goals and timetables. Yes only DDs can upload packages to the ftp server. But even there the ftpmasters look at packages and check them before they go into the distribution. Anyone can join one of the packaging teams and submit a package into a debian subversion or git repo. I have contributed many packages over the years and am not a DD, nor do I feel the need to be one since I can get the software I want into debian so easily. It isn't really fair to say that Debian lacks openness. The consistent and tested set of packages are then not touched (apart from critical security patches) for the next 18 months or so while the next release is prepared. That is not the model the Maemo community members want as they want to be able to create and launch new applications and new versions of applications in days, not months. Debian testing is closer to the release goals of Maemo (although still quite far away -- it takes a long time for something to propagate into testing and relatively few new packages are added). But Debian testing requires frequent updates of all parts of the system, and no guarantees of support. Actually not true. Debian has had security for testing for about four and a half years. http://lists.debian.org/debian-devel-announce/2005/09/msg6.html The Debian community is very clear that only people who can tolerate occasional broken systems, and continuous change, should install testing. I think you are referring to unstable here. I run testing everywhere, even production web servers, and I have few problems. Especially compared to the Ubuntu machines I admin, or for that matter, fedora. As each project has different goals, and constraints, the decisions made around process (including how builds and repositories work, who can submit code, how QA works, etc.) are going to be very different. But suggestions or comments from people familiar with how other projects work are certainly welcome. 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 think debian should server as a model for maemo, after all, Nokia based its OS on debian. The biggest problem is Nokia's penchant for separating their releases from the community. There really should be greater cooperation between the community and Nokia, it is pretty much as simple as that. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
On Jan 20, 2010, at 23:21, Ryan Abel wrote: On Jan 20, 2010, at 1:04 PM, Jeff Moe wrote: I've seen frequent mentions of how distinct maemo.org is from Nokia. But the reality seems that nothing at Maemo can really happen without Nokia's tacit approval. Is there anyone that has server access that isn't paid (directly or indirectly) by Nokia? Can we start getting the servers admin'd by community admins instead of depending upon Nokia? A first step would be to document (on the *outside/public*) wiki the current server arrangement. Another good step would be to get DNS off their servers. Until that happens, the whole maemo is distinct from Nokia is just a façade. Maemo is a trademark owned by Nokia and used for their software platform and their products. You're confusing Maemo and maemo.org (maemo.org being the community-owned website). In doing so, you're confusing the discussion and making it much more difficult to participate and arrive at a useful conclusion. Maemo and maemo.org are not equivalent interchangeable terms. Nor are they as distinct as you would imply. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
On Jan 19, 2010, at 10:13 AM, tero.k...@nokia.com tero.k...@nokia.com wrote: Some gems: 1) It's also important to set up an official web site which is down as often as it's up. It's not enough to have no web site at all; in such situations, the community has an irritating habit of creating sites of its own. But a flaky site can forestall the creation of those sites, ensuring that information is hard to find. As maemo transitions to a much larger server farm, there have been hiccups. The site has been slow, but has recently gotten significantly faster, in certain parts. Tero is right though, you just haven't been here long enough to have a reliable sample of uptime vs. downtime with regards to maemo.org. 3) There should be no useful information about the code, build methods, the patch submission process, the release process, or anything else. Then, when people ask for help, tell them to RTFM. I dismiss this out of hand. Yes there are places where things could be better documented, but there is a huge body of documentation out there, much of it well written and openly editable. 4) Project decisions should be made in closed-door meetings. 5) Employ large amounts of legalese. 7) Keep the decision-making powers unclear Unfortunately a bit of this is true. But this is part of maemo's dual nature, the half-closed, half-open beastie. To be honest, in a project like debian the entire infrastructure is open to debian developers so there is no closed-door, no cabal. Maemo could do better here. 8) Screw around with licensing. Community members tend to care a lot about licenses, so changing the licensing can be a good way to make them go elsewhere. Even better is to talk a lot about license changes without actually changing anything; You'll have to point to some evidence for this to apply to maemo. The only license changes I have noted are those that go from closed to open, stuff from TI for example. (Thanks again keepsie!) 10) Silence. Don't answer queries, don't say anything. A company which masters this technique may not need any of the others; it is the most effective community destroyer of them all. If you start a discussion in a tone of voice that is asking for a fight, we often disregard the discussion. We aren't here to pick fights, but to try and do something productive. You do get many things done, but your communication style isn't polite. I do understand that controversy can bring about change, but it can also polarize situations. Ooops! No silence here! I guess that disproves point 10. :-) (http://jaaksi.blogspot.com/ -- More non-silence.) Jeremiah As a post script I will add that the maemo community is one of the friendliest communities I have been involved with on the interwebs. Of course the two communities I regularly lurk in, debian and perl, are a bit notorious, but maemo is genuinely friendly. There is plenty of room for criticism, just try to be polite so that the tenor and tone remain positive enough for people to get work done and not get distracted by pejorative attacks. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: running application automatically at system startup
On Jan 19, 2010, at 11:02 AM, Dave Neary wrote: Hi, Edward Page wrote: Is anyone collecting these How do I... questions and putting them on the wiki? http://wiki.maemo.org/Tutorials http://wiki.maemo.org/User_FAQ http://wiki.maemo.org/Developer_FAQ Psst... don't tell anyone, but it's a wiki. Dave! Why did you say that? Now everyone knows that _anyone_ can edit it! Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
On Jan 19, 2010, at 15:20, Michael Cronenworth wrote: The user will be told why they can't update their little fart app. We don't have fart apps in Maemo. You're thinking of the iPhone. /facetiousness Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Package building error with the armel target
On Jan 15, 2010, at 12:30 AM, Petite Escalope wrote: Hello, I'm trying to build a package for the armel target but it fails on this error : dpkg-genchanges -b dpkg-genchanges: failure: cannot read files list file: No such file or directory Everything is working with x86 What's the problem? In general dpkg-genchanges wants to see a file called debian/files to generate a .changes file for the eventual deb. Do you have a debian/files file? Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras-devel repository index out of control?
On Jan 15, 2010, at 10:27 AM, Marius Vollmer wrote: 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. With the new repository tool we're going to use (reprepro) that problem will disappear because it is significantly easier to manage what is in the repos and to move old packages cleanly. This will shrink the repos and the resulting index files. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: User-specific files for maemo packages
On Jan 11, 2010, at 9:55 PM, Till Harbaum / Lists wrote: Hi, Am Montag 11 Januar 2010 schrieb ibrahim: I wonder how can I put some user-specific files on the filesystem that can't get removed when my application package is uninstalled. I am not sure that this is a good idea. The user should have the right to remove your application data if they want to. Don't create the directory through the debian package, but let the application create the directory when there's a need (e.g. just when you want to store your app specific files). This is most likely a good idea. There are a number of places specified by the FHS as to where exactly you should put user data, depending on how long you want it around, if it is a config file, or the type it is stored as. In any case, this is not something you do in your package but rather in your application while interacting with the file system. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: is 44-1 officially going to be available as an image ?
On Jan 12, 2010, at 1:16 PM, Till Harbaum / Lists wrote: Hi, Am Dienstag 12 Januar 2010 schrieb Mikko Vartiainen: Any idea why my n900 doesn't see the update? Have you accidentally removed SSU metapackage (mp-fremantle-generic-pr)? Yes, i did. I once removed those pre-installed games using apt-get. And since the metapackage had a dependency on these, it was also removed. Fortunately a simple apt-get install mp-fremantle-generic-pr gave me a successful update. But i assume this is pure luck as apt-get doesn't do all the magic the application installer does to make sure the installation succeeds. The correct solution probably is to install the old version of this package using apt-get and then let the app installer do the update. In fact in my case, I cannot upgrade. I presume I deleted the old mp-fremantle-generic-pr package, dpkg -l | grep mp-fremantle-generic-pr reveals nothing. When trying to install it, I get a message about broken depends. r...@nokia-n900-41-10:~ apt-get install mp-fremantle-generic-pr Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: mp-fremantle-generic-pr: Depends: cmt-firmware-rx51 (= 8.2.2009.34.3-2+0m5) but 8.2.2009.34.2-2+0m5 is to be installed Depends: hildon-initscripts (= 1.26-1+0m5) but 1.26-1+dp1 is to be installed E: Broken packages Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: can't install application to phone from local repository
On Jan 6, 2010, at 14:05, ibrahim wrote: Kees Jongenburger wrote: Hi ibrahim, On Sun, Oct 25, 2009 at 11:37 AM, ibrahim ibrahim@asgatech.com wrote: you might want to look a what extra's devel's structure looks like #source.list #extras-devel deb http://repository.maemo.org/extras-devel/ fremantle free non-free deb-src http://repository.maemo.org/extras-devel/ fremantle free but on on the website http://repository.maemo.org/extras-devel/dists/fremantle/free/ notice the dists and the location where the Packages file ends up http://repository.maemo.org/extras-devel/dists/fremantle/free/binary-armel/Packages The thing also is that your package has arch set to all. but start looking at your servers logs. Greetings I did exactly the same as Maemo extras repository did on my local reposidtor , the same folder structure /dists/fremantle/free/binary-armel/ Turns out that is not exactly the same. Try /extras-devel/ as a replacement for your dists If you are setting up a test repo, or even a local mirror of one of the repos, I highly recommend using reprepro. I have written about it here: http://wiki.maemo.org/Reprepro. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Mirrors
On Jan 3, 2010, at 12:22, David Greaves wrote: Jeff Moe wrote: As far as I can tell, there are no mirrors of the repositories. Pretty sure Nokia/maemo.org went with a CDN which satisfies all the points you raised. The maemo.org infrastructure problems are more to do with dynamic content and build services and are being addressed AFAIUI. David is right on both counts. Most free software projects do have mirrors but we are lucky in having Nokia as a partner in Maemo because they have taken on the significant cost of pushing maemo.org content to mirrors. In this case the mirrors are a top notch Content Delivery Network. Garage is being replaced, you can see lots of information about that progress on Maemork: http://www.qaiku.com/channels/show/maemork/ Garage has been a victim of its success and of the significant growth that maemo has seen. Many people are working hard to make sure that garage will continue to work smoothly for the whole community. I personally am working towards that goal and I know that teams inside and outside Nokia are working towards that too. Jeremaih ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Jan 2, 2010, at 21:54, Andrew Flegg wrote: On Sat, Jan 2, 2010 at 20:47, Micke Nordin mickew...@gmail.com 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. To stay abreast of these changes it would be great if we had a canonical document about this so that we could move information from the wiki to the Packaging pdf for example. Where does that canonical document reside now? For example, I see nothing in the current packaging document: http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging,_Deploying_and_Distributing I am happy to add information there from disparate sources but if there is already a canonical source I'll copy that. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Mirrors
On Jan 3, 2010, at 17:37, Jeff Moe wrote: On Sunday 03 January 2010 11:45:17 Jeremiah Foster wrote: On Jan 3, 2010, at 12:22, David Greaves wrote: Jeff Moe wrote: As far as I can tell, there are no mirrors of the repositories. Pretty sure Nokia/maemo.org went with a CDN which satisfies all the points you raised. The maemo.org infrastructure problems are more to do with dynamic content and build services and are being addressed AFAIUI. David is right on both counts. Most free software projects do have mirrors but we are lucky in having Nokia as a partner in Maemo because they have taken on the significant cost of pushing maemo.org content to mirrors. In this case the mirrors are a top notch Content Delivery Network. * That doesn't make us lucky. Pretty ungenerous of you. I think that maemo is extremely luck to have a corporate sponsor who puts up with the criticism, justified and unjustified, that we all throw at it. Of course there is something in it for them, but the infrastructure isn't free. Trust me, Red Hat does help Fedora out of the goodness of their heart either. And HP has been a very good friend to debian. The repositories are frequently down. If there were mirrors we could just point at the mirrors. They were down yesterday, for instance. * Why not complement this top notch service with mirrors and get the best of both? Maybe we ought to have an official mirror service, not necessarily a bad idea. * I'm not talking dynamic content here. I'm talking a simple http repo. I understand that mirroring dynamic sites like talk, the wiki, bugzilla, etc. are harder to mirror. Um, several gigs of debs and gigs of bandwidth is non-trivial. This will cost. And that is just repos. * Every other single distro of note, whether community, corporate, or a mix has a mirror. Can you point me to one that doesn't? What makes Nokia's way so much better? Again, it would be much more convincing if it actually *worked* reliably. Bugs URLs please. Hard facts please, stuff we can present to Nokia and say: Akamai is not performing. What's the downside to having mirrored content? Keeping it in sync. Another resource to monitor, yak shaving, etc. Garage is being replaced, you can see lots of information about that progress on Maemork: http://www.qaiku.com/channels/show/maemork/ Lots of infomation? Like an occasional tweet? I have been following that. You undermine your argument when you become pejorative and dismiss out of hand the significant work being done. http://wiki.maemo.org/Maemo.org_Sprints/December_09#Tasks Plus there is lots of stuff happening behind the scenes. I agree that we should be more communicative about this, but it is happening. Garage has been a victim of its success and of the significant growth that maemo has seen. Many people are working hard to make sure that garage will continue to work smoothly for the whole community. I personally am working towards that goal and I know that teams inside and outside Nokia are working towards that too. Yes, garage is slow and that is a bit understandable. Even that could be mirrored I'm guessing since sourceforge has lots of mirrors when you go to download and garage is running sf-esque code. But I wasn't talking about garage in particular, I was talking about the repository. Surely the repository functioning isn't dependent on garage code. If so, garage should sync that over to another box which can be sync'd publicly. Garage runs it all. The repos, the web site, gforge, etc. There are some other resources but nothing significant. This is all getting built out by an order of magnitude. But it takes time because obviously we want as little downtime as possible. Again, what's the downside to following the tried and true practices of every gnulinux distro of the last decade+? The repositories are a public resource. Nothing but time, cost and energy stop you from mirroring them yourself. Having an infrastructure to mirror different from Akamai might be good either as a redundancy measure or as an emergency resource. I think you'll find it non-trivial and your time will be better spent helping the new infrastructure and pointing out where Akamai fails to deliver so we can fix it. -Jeff P.S. Tangentally: change your /etc/resolv.conf nameservers and you get a different download server. Sounds like intentional Akamai magic. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder apt-get problems = failing builds
On Jan 3, 2010, at 19:50, Andrew Flegg wrote: On Fri, Jan 1, 2010 at 14:37, Ed Bartosh bart...@gmail.com wrote: Anyway it was not working for a long time and people became confused. Would some kind of Big Brother/Tivoli/monitoring system be worthwhile investigating? And now I'm restarting all those 40 builds manually. I've a problem - the x86 build of vim 7.2.0-maemo6 shows up in maemo.org/packages/ but not the armel version: http://maemo.org/packages/view/vim/ Obviously reuploading it gets it rejected. Easy fix or do I need to upload another version? Would you try just bumping your version? i.e. 7.2.0-maemo7? Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Mirrors
On Jan 3, 2010, at 20:13, Jeff Moe wrote: On Sunday 03 January 2010 15:28:04 Jeremiah Foster wrote:. Bugs URLs please. Hard facts please, stuff we can present to Nokia and say: Akamai is not performing. The only bug I know of is: https://bugs.maemo.org/show_bug.cgi?id=5818 I have created http://wiki.maemo.org/Mirrors to see if anyone else has issues and to try and have a central place for mirror issues. To collect these hard facts a procedure would need to be written up so end users can report their outages. I can write something up on the wiki, but I have a feeling I'll be flamed if I do so. I will anyway, if you like. But where should the end users report the outages? Plus there is lots of stuff happening behind the scenes. I agree that we should be more communicative about this, but it is happening. OK. I have emailed coun...@maemo.org about this, per suggestion of stskeeps. Good. The council should definitely be involved. Again, what's the downside to following the tried and true practices of every gnulinux distro of the last decade+? The repositories are a public resource. Nothing but time, cost and energy stop you from mirroring them yourself. Having an infrastructure to mirror different from Akamai might be good either as a redundancy measure or as an emergency resource. Done. Copying over at the moment to my server at netdepot.org. Wrote up mini- HOWTO: http://wiki.maemo.org/User:Jebba/Mirror Can you use reprepro to mirror the repos? It is far and away the best tool to do that sort of thing (it used to be called 'mirrorer') and is a debian native project. Good documentation plus very responsive upstream. Can you give me a log in to your machine? Then we can do some testing and expose reprepro and the repos to other testers as well. Currently the reprepro installation I did on stage.maemo.org is not publicly visible. I think you'll find it non-trivial and your time will be better spent helping the new infrastructure and pointing out where Akamai fails to deliver so we can fix it. What can I do to help out with the new infrastructure? I think there is a lot one can do. I would love to organize a team to manage the repos. Teams are used in debian for nearly every task and it spreads the responsibility and points of contact. I would love it if we could collaborate on a SOP for the repos. Hopefully the repos will be free of any secret software that requires an NDA to work on (part of the problem with a half closed, half open project). In any case, a SOP would be a great start. Would you be interested in working on a repo team? Anyone else interested? Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Mirrors
On Jan 4, 2010, at 24:28, Jeff Moe wrote: It wasn't my intention to provide some big mirror for people to use myself, I was just suggesting the project have mirrors. Oh, I misunderstood. I thought you were offering to mirror the repos publicly. You just want your own local mirror. That makes sense, and can make life a lot easier. I still recommend reprepro, it is a fantastic tool. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder apt-get problems = failing builds
On Jan 1, 2010, at 15:00, Ed Bartosh wrote: 2010/1/1 Andrew Flegg and...@bleb.org: Hi, Attempting to upload a new version of vim to the Fremantle auto-builder, I get the following failure: https://garage.maemo.org/builder/fremantle/vim_7.2-0maemo6/armel.root.log.FAILED.txt Should be fixed now: https://garage.maemo.org/builder/fremantle/vim_7.2-0maemo6/ Thanks for pointing out to this. Somebody's changed sbdmock configuration on the build host. I don't know why, because it was working just fine before. This reminds me aphorisms like 'Too many cooks spoil the broth' or 'Many commanders sink the ship. I like better Russian one 'Seven babysitters have a child without eye'. Autobuilder reminds me that child sometimes. Funny, I was thinking the exact opposite. If more people had access, then more than one person could fix it. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Uploading software to Maemo repos
Hi Bryan, My name is Jeremiah Foster and I am the debmaster at maemo.org. I have seen a lot of your uploads recently which duplicate what already exists in the maemo repositories. In fact, some of these things, like debconf for example, might conflict with the development environment. Can you tell me your intentions? What are you trying to build? And have you read the appropriate documentation? Thanks, Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder apt-get problems = failing builds
On Jan 1, 2010, at 15:12, Ed Bartosh wrote: 2010/1/1 Jeremiah Foster jerem...@jeremiahfoster.com: On Jan 1, 2010, at 15:00, Ed Bartosh wrote: 2010/1/1 Andrew Flegg and...@bleb.org: now why, because it was working just fine before. This reminds me aphorisms like 'Too many cooks spoil the broth' or 'Many commanders sink the ship. I like better Russian one 'Seven babysitters have a child without eye'. Autobuilder reminds me that child sometimes. Funny, I was thinking the exact opposite. If more people had access, then more than one person could fix it. I doubt that. What I can see is that more people can break it. If you need a proof - give everyone root access to that box :) Seems to work for debian. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Uploading software to Maemo repos
On Jan 1, 2010, at 16:22, Bryan Jacobs wrote: Jeremiah, I needed ss-dev, debconf-utils, and a few other packages which *were* built from the Nokia official sources but which *were not* present in any repository I could find. The packages I built which are also in the official Nokia repository (e2fsprogs and debconf) are unmodified and constructed via apt-get source; dpkg-buildpackage. They will not go through - there is a check on the builder that prevents that sort of thing from happening, though the check sometimes fails. Do you read your build logs? Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder apt-get problems = failing builds
On Jan 1, 2010, at 16:00, Jeff Moe wrote: On Friday 01 January 2010 11:37:24 you wrote: 2010/1/1 Jeff Moe m...@blagblagblag.org: On Friday 01 January 2010 11:12:47 Ed Bartosh wrote: 2010/1/1 Jeremiah Foster jerem...@jeremiahfoster.com: On Jan 1, 2010, at 15:00, Ed Bartosh wrote: 2010/1/1 Andrew Flegg and...@bleb.org: Hi, Attempting to upload a new version of vim to the Fremantle auto-builder, I get the following failure: https://garage.maemo.org/builder/fremantle/vim_7.2-0maemo6/armel.roo t.l og.FAILED.txt Well, you'd have a better case if things worked more reliably. Anyway it was not working for a long time and people became confused. And now I'm restarting all those 40 builds manually. I think we should look to Fedora since they have a similar arrangement: community distribution with corporate overlord. This is how they do it: * IRC channel of admin issues: #fedora-admin and #fedora-noc where you can watch things live. Good idea. * Standard Operating Procedure for outages: https://fedoraproject.org/wiki/Outage_Infrastructure_SOP Really good idea, we should have an SOP for that. * *PAGER* access, available to the public, where you can page one of 9 admins (a bit unbelievable, actually): https://admin.fedoraproject.org/pager I don't want to wear a pager, and I don't think it is necessary, but still. * More people would know how the whole *.maemo.org infrastructure actually worked if information about it was public. The joke is that it runs on a N700. It's no joke. /sarcasm Nokia is doing a lot to address the infrastructure problem. Part of it comes from the open / not open split and how a International Corporation deals with integrating Free Software developers into a corporate workflow. Nokia is not perfect, but they are willing to learn and work hard, so I thin being patient here is worth your while. Red Hat has not been prefect here either. But people can make this joke because the actual server set up is known by only a few. Compare that to this dream: https://fedoraproject.org/wiki/Category:Infrastructure_SOPs This is awesome, I think this is a good idea. Part of the problem has been critical mass - we haven't had enough developers willing to take on these kind of issues, Nokia has had to provide it or recruit people. We have grown a lot in 2009 so maybe we can get teams from the community to do this sort of work. Anyway, they are doing things far better and I don't see people griping about outages over there much at all. Different project, different goals, they've been around a lot longer (they were once Red Hat remember) and they have a lot of experience. You have to give credit to Nokia and the people who work hard on the infrastructure - they do a lot of really hard work and this whole experiment is fairly new for Nokia. I am confident the whole process will improve. What's the procedure for Maemo? Dive into #maemo-devel and hope someone knows WTF is up? Their answer is usually wait for x-fade. Post to talk.m.o.? Hit reload on qaiku? Post a comment there? Add more here? https://bugs.maemo.org/show_bug.cgi?id=5818 Surprisingly I was told by an @nokian that reporting to that bug *was* the correct place to report outages (!). I think it would be less than honest to not say this is suboptimal. Anyway, there are organizations all around the world that run servers 24/7/365 with minimal outages that have more than 2 admins with access. That is obvious. The maemo infrastructure is no where near approaching 99% uptime (let alone .999s). A mere 40 submitted builds is also a loss of time and momentum of many developers... Nokia is a handset maker. They are not a company that does a lot of public facing internet server work. That is changing. Constructive criticism from the community will help, like the good examples you have linked to. We as a community need to continue to show a good example and demonstrate to Nokia that we are reliable and reasonable, then we can build out maemo into something we are proud of. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Daemonizing Qt app
On Dec 31, 2009, at 16:42, ibrahim wrote: case SIGHUP: log_message(LOG_FILE,hangup signal catched); Sorry to be pedantic, but the past tense of 'catch' is 'caught'. 'Catched' might be confused with 'cached' which is not what you want. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How remove package from extra-devel free?
On Dec 19, 2009, at 11:07, Arkady Glazov wrote: Hi, Can i drop my unuse pacakge from Maemo extras-devel repositories? Yes. In general it is best to contact someone about a package you want removed, usually that someone is Niels or myself. :) Is there any interface for it? At the moment no, but there will be in the future since this request is common. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debhelper 7
On Dec 14, 2009, at 14:02, Anderson Lizardo wrote: On Mon, Dec 14, 2009 at 7:15 AM, Marius Vollmer marius.voll...@nokia.com wrote: On balance, I think it is better to just stick to debhelper 5 in Fremantle. And from our experience in PyMaemo backporting various (but not that many) packages from debhelper compatibility level 7 to 5, in most cases you need just to change: * 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. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debianisation help with packaging libgmphoult
On 12/6/09 12:37 PM, Simon Pickering wrote: Hello everyone I've packaged up and pushed libgmp to extras-devel, but obviously made a mistake in the Debianisation as it's trying to install a file to my build directory (so don't try installing it yet). I can guess why the code I inserted is wrong, but can't work out what to put in to actually make it work. I've tried altering the rules file, but to no avail. We're talking about the debian/rules file in the install: section, which currently looks something like this (tabs removed). install: build-stamp install-prep $(MAKE) DESTDIR=`pwd`/debian/tmp -C build install dh_install --sourcedir=$(CURDIR)/debian/tmp -plibgmp3c2 usr/lib/libgmp.so.* dh_install --sourcedir=$(CURDIR)/debian/tmp -plibgmp3c2 usr/lib/libmp.so.* dh_install --sourcedir=$(CURDIR)/debian/tmp -plibgmpxx4ldbl usr/lib/libgmpxx.so.* dh_install --sourcedir=$(CURDIR)/debian/tmp -plibgmp3-dev usr/lib/lib*.so dh_install --sourcedir=$(CURDIR)/debian/tmp -plibgmp3-dev usr/lib/lib*.a dh_install --sourcedir=$(CURDIR)/debian/tmp -plibgmp3-dev usr/lib/lib*.la dh_install --sourcedir=$(CURDIR)/debian/tmp -plibgmp3-dev usr/include dh_install --sourcedir=$(CURDIR)/build -plibgmp3-dev -Xgmp-mparam.h usr/include/gmp*.h # dh_install -plibgmp3-dev build/gmp-arm.h $(CURDIR)/debian/tmp/usr/include # Install upstream ChangeLog, AUTHORS, NEWS, and README only in -dev package dh_installchangelogs -plibgmp3-dev dh_installdocs -plibgmp3-dev AUTHORS NEWS README The build/packaging failure message is this: dh_install --sourcedir=/home/simon/build/Octave/gmp/gmp-4.3.1+dfsg/build -plibgmp3-dev -Xgmp-mparam.h usr/include/gmp*.h dh_install: libgmp3-dev missing files (usr/include/gmp*.h), aborting This part should install the arch specific header file (e.g. gmp-arm.h) from the $(CURDIR)/build directory. I put in the commented out line (just after the one I repeated above) which worked, but fails for the x86 build of course, so back to something generic. The gmp-arm.h file that I'm interested in installing does exist in the $(CURDIR)/build directory just in case you were wondering. Any help appreciated. Shouldn't CURDIR be defined earlier? It seems it is being defined _after_ you're doing dh_install. I'll look a little more closely at the dh_install man page to see if I can help diagnose with a little more detail. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt or GTK+ which is better for developement
On Dec 3, 2009, at 12:07, Abdul Mateen wrote: Yes, I think I should start by developing on Qt for Maemo 5 and onwards, I am also curious about distribution of applications, like Android has Android Market maemo has Maemo Select but I saw one can not push paid apps into Maemo Select. Any news nokia is going for an app store for Maemo ? Ovi is going to be (potentially) a paid app store for Maemo. Note that there already are thousands of apps available through apt-get and they are free. Maemo is based on debian which is a Free Software GNU / Linux distribution, so many of the libraries use LGPL or the GPL. This may have a bearing on your apps, so it often pays to understand the licenses before you start distributing your software. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt or GTK+ which is better for developement
On Dec 3, 2009, at 15:31, Murray Cumming wrote: On Thu, 2009-12-03 at 13:31 +0100, Jeremiah Foster wrote: [snip] Maemo is based on debian which is a Free Software GNU / Linux distribution, so many of the libraries use LGPL or the GPL. This may have a bearing on your apps, so it often pays to understand the licenses before you start distributing your software. That's unnecessarily alarmist. The licenses (such as LGPL, MIT) used by typical Maemo APIs create no significant problem for distribution of applications built on the platform. I don't see how it is alarmist to point out the licenses used. Many developers do not understand the implications of using Free Software licenses, especially those who come from proprietary software backgrounds. Whatever software you use, you should understand the license it is under. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Maemo superstars wanted on stackoverflow
Hi, Do any Maemo superstars want to post to Stackoverflow? There are some Maemo related questions there and they are not necessarily being answered by those who have the most knowledge in our community. I know that we can be pretty hermetic at times, sticking to our forums and mailing lists, but there is a whole world out there! With people thirsting for Maemo knowledge! http://stackoverflow.com/questions/423595/how-to-get-started-with-maemo-software-development Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debhelper 7
On Nov 28, 2009, at 16:00, Teemu Ikonen wrote: On Sat, Nov 28, 2009 at 3:02 PM, David Greaves da...@dgreaves.com wrote: Do you have a URL for the .dsc and tarball You can check out the sources by doing git clone git://gitorious.org/maemo-pkg/debhelper.git But, as said, the build fails. I know that Nokia sort of disables perl on the device - they might do that on the SDK as well. Have you installed the perl-moduels package as well as perl-base in the SDK? Teemu Teemu Ikonen wrote: Hi, I'm trying to compile / port some C libraries from Debian to Maemo 5. The actual compilation goes without problems, but the packaging scripts use the (very nice) command sequencer functionality of debhelper v. 7, while the SDK has only debhelper 5. This is excellent - I would love to see this in maemo because it makes the rules files so simple. 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. Has anyone else tried or managed to get debhelper 7 running on maemo 5? Having to rewrite the packaging on every library I need would be a major suck. Teemu Let me know how I can help. Perhaps post your error message here when building? Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Updating the info for Extras-devel non-free
On Nov 27, 2009, at 11:15, Quim Gil wrote: Hi, ext Jeremiah Foster wrote: I am hesitant here, some of the testing process may require source packages, either now or in the future. I am not certain that non-free packages deserve to get all the free quality assurance that the community provides. I think they should be grateful that they are included at all and if they want to go through testing, they need to at least provide a source package. I think this had been discussed before. At least I remember a reply from Henrik (Mauku developer) explaining in quite plain English why even if source code availability is the ultimate resource for good testing, in practice most apps go through the QA without anybody checking that source, and even many tools analyzing power consumption and performance will check the binaries and not the source packages. Yes that's true for the testing process. Maemian, a part of the QA process but not part of the testing / promotion process, works only on debs so it requires source code. So the questions is in fact non-technical: - Do you want non-free apps showing up in http://maemo.org/packages/repository/qa/fremantle_extras-testing/ ? My personal answer is no. - Do you want non-free apps showing up in http://maemo.org/downloads/Maemo5/ ? There I don't care so much. My personal opinion is that maemo.org has been always strong in open source but not exclusive, just like Maemo itself. In practice many users and developers got their first contact with free software thanks to this hybrid approach, and now some of them are in the first row of OSS evangelists. I agree with you, if the community wants non-free apps in the repos then that is good enough for me. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Updating the info for Extras-devel non-free
On Nov 25, 2009, at 11:49, tero.k...@nokia.com tero.k...@nokia.com wrote: -Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers- boun...@maemo.org] On Behalf Of Gil Quim (Nokia-D/Helsinki) Sent: 25 November, 2009 11:48 To: maemo developers Cc: marc...@maemo.org Subject: Updating the info for Extras-devel non-free Hi, the information to upload binary-only packages to extras-devel is out of date: http://wiki.maemo.org/Uploading_to_Extras-devel#.22non-free.22_packages As far as I know, for Fremantle you follow the normal rules. Upload to extras-devel and promote. But Niels is the authority on that. We have had an ad-hoc solution which basically is that Niels takes care of non-free. Yet there are several non-free packages in extras-devel extras- testing / Extras. Can someone please update the wiki information reflecting the current practice for Maemo 5? This may require long discussions on what is non-free and why it should be there. Perhaps the current ad-hoc situation is preferable. We are seeing more questions about this and actually the current information is misleading since it suggests that non-free packages can bypass the Extras-testing QA process, which is not true. I am hesitant here, some of the testing process may require source packages, either now or in the future. I am not certain that non-free packages deserve to get all the free quality assurance that the community provides. I think they should be grateful that they are included at all and if they want to go through testing, they need to at least provide a source package. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Updating the info for Extras-devel non-free
We have had an ad-hoc solution which basically is that Niels takes care of non-free. Yet there are several non-free packages in extras-devel extras- testing / Extras. Can someone please update the wiki information reflecting the current practice for Maemo 5? I will try and make it clear: there is no actual information or policy on the procedure of non-free packages and testing. Certainly not as communicated to me. Generally what happens is people are told to get in touch with Niels and he uploads the binaries to non-free. Here is the relevant line that I believe X-fade added regarding this: There is no promotion available for non-free. You need to upload yourpackage to the right repository yourself. When he states 'promotion' he is referring to extras-testing. This may require long discussions on what is non-free and why it should be there. Perhaps the current ad-hoc situation is preferable. We are seeing more questions about this and actually the current information is misleading since it suggests that non-free packages can bypass the Extras-testing QA process, which is not true. I am hesitant here, some of the testing process may require source packages, either now or in the future. I am not certain that non-free packages deserve to get all the free quality assurance that the community provides. I think they should be grateful that they are included at all and if they want to go through testing, they need to at least provide a source package. It is preferable that we make sure the wiki reflects reality rather than just changing things on the fly. This page; http://wiki.maemo.org/Uploading_to_Extras-devel#.22non-free.22_packages stated that non-free packages go through the same testing procedure as free packages. This is not the case. Let's wait until Niels comes back so that he can explain exactly what his code does, then we can decide if we want to change the policy. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Updating the info for Extras-devel non-free
On Nov 25, 2009, at 15:11, Valerio Valerio wrote: Hi, On Wed, Nov 25, 2009 at 1:55 PM, Dave Neary dne...@maemo.org wrote: Hi, I know I'm not the only one confused here... Quim says: We are seeing more questions about this and actually the current information is misleading since it suggests that non-free packages can bypass the Extras-testing QA process, which is not true. And Jeremiah says: Here is the relevant line that I believe X-fade added regarding this: There is no promotion available for non-free. You need to upload yourpackage to the right repository yourself. When he states 'promotion' he is referring to extras-testing. This directly contradicts what Quim said - either non-free packages bypass the extras-testing QA process, or they don't. Which is it? It is what the code allows it to be. In other words, if Niels says it does not go through promotion, and he wrote the code, then I think it doesn't go through promotion. It is preferable that we make sure the wiki reflects reality rather than just changing things on the fly. This page; http://wiki.maemo.org/Uploading_to_Extras-devel#.22non-free.22_packages stated that non-free packages go through the same testing procedure as free packages. This is not the case. I put this in place today, following Quim's mail. Previously it said It's your responsibility to upload to the right place or something like that. Let's wait until Niels comes back so that he can explain exactly what his code does, then we can decide if we want to change the policy. Perhaps part of Niels' tasks when he comes back should be to ensure that we don't need him to come back to explain what policy is? It seems like an awful lot of things depend on him being around. Totally agree. We all should be easily replaced. The code we write, what we do, how we administer the servers, should all be documented. This fortunately is pretty much the case with what you do Dave, but I think the rest of us, myself included, have been less effective at documentation. I wrote an email about this to the internal team list, but it got little response. I think the maemo council should really take this up, if the council wants an overview of what the staff they have hired are working on, they should make sure documentation is available. Only then can they know if they need more staff, different staff, or what the staff actually does. It would also help me explaining what I do to the council. I will start working on a Log Book where I describe the code I write to do BAU and what pieces of garage I am personally responsible for. Here's a example of a non-free package: http://maemo.org/packages/package_instance/view/fremantle_extras-devel_non-free_armel/fring/1.2.1.64-1 It seems to have a similar page structure to the other free apps on package interface, don't know if there's a promotion button there(I'm not the maintainer), but if no is because Neils disable it. On a related topic is STILL possible to create a page at maemo.org and insert a .install file pointing to a external repository, bypassing all the QA Criteria (someone already did that :( ). We should discuss this in relation to QA at the next sprint and see if we can come up with a way to deal with it. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Updating the info for Extras-devel non-free
On 11/25/09 4:07 PM, Andrew Flegg wrote: On Wed, Nov 25, 2009 at 14:55, David Greavesda...@dgreaves.com wrote: Does the community really have so much spare resource that we can QA non-free (and presumably non-community) apps? fms/RST38h's emulators are non-free. However much I'd prefer to have the source and not special case them, they are useful packages and the author's intention should be respected. I don't think the author's rights trump the community's rights. Do I want him to go off and create a new repo? No. This is not necessarily what will happen if we ask for source. Is Ovi an alternative? We don't know yet. That seems to be a one way street - they can take maemo.org packages, but we have no access to their repos. However, having tested earlier versions of VGBA, iNES and others, I think I can say they went through the normal testing procedure, despite being non-free. The reason pre -testing they went directly to Extras was that there was no point going through the auto-builder. Now, however, I think they should be going directly into -devel and promoted into -testing and Extras proper as per free packages. Maemian is designed to peer into debs, to find 'bugs' in packages, not in software, it is designed to be part of the QA process after the build on garage. It will not run on debs that haven't gone through the build system. So at least part of the QA process will not work on non-free apps. Whether they get highlighted in a different queue is an interesting question; but will probably push non-Ovi, non-free apps away into their own repositories. One of the things that the maemo version of debian's popularity contest is hopefully going to do is to check the repos being used on the device. This might show us how widespread the use of outlying repos is. It might also be an effective way of piercing this argument, I don't think it is as widespread a practice as it used to be. The point of community QA is to make sure only good apps get to users: we're doing it because we're selfish. It's not free bug finding for commercial software teams; and so saying we're only go to QA it for you if you give us the source would seem to be a change in the purpose and intent of the QA process. I think you make a powerful argument that the QA process is for users to get good software. However, software developers target distributions like debian because of its quality assurance, and if Maemo gets a reputation for quality, then one can expect that sort of targeting to occur there as well. It is perfectly reasonable to expect that those who participate in the QA process adhere to the same principles of openness that have made maemo.org so successful. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: how to create a desktop applet
On Nov 18, 2009, at 9:19, ibrahim wrote: Didn't work either. Maybe there is something wrong with the way i create packages: There isn't really a wrong or right way, just a way that works for you and allows the package to be installed according to policy. That said, there are some 'best practices' that will make your life easier. the steps i take to create the package are : 1. compile the source and header using gcc inside scratchbox * gcc -shared 'pkg-config hildon-1 libhildondesktop-1 --libs --cflags' example.c example.h -o output.so 2. create the folder structure : data/usr/lib/ and put the output.so file inside it 3. create the folder : data/usr/share/applications/hildon-home and put the .desktop file inside it 4. create the DEBIAN/control file and supply the package information in it You may want to look at dh-make. This program creates a whole bunch of skeleton files and directories which can provide a template for your package. You just have to edit the files you want and make them relevant to your package. The debian New Maintainers Guide describes this process in detail. You get the added benefit that your eventual package is installable on a number of OSes, like Ubuntu, Mepis, debian, etc. 5. rename the parent folder to : appname-version|| 6. |run the command : dpkg-deb --build app-folder| Like Kimmo mentioned, using dpkg-buildpackage is probably a best practice. I think this is the command used most often both in Maemo and in debian which means you will have lots of help if you run into some weird behavior. 7. then setup the package to the emulator using dpkg -i packagename.deb 8. in the emulator; press on the upper area of the desktop, and enter the desktop menu 9. click on the Desktop menu --- add widget --- didn't find my application name in the widgets menu !!! what's wrong with what i've done ?? can anybody help? I think following Kimmo's advice would be an excellent way to go. :-) Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: no such file or directory
Hi Mohamed, On Nov 16, 2009, at 11:26, mohamed ismael wrote: It is customary to post your comments directly underneath the comments that were sent to you. This way we can 'weave' together a conversation that everyone can follow. :) i added the following line in my code #include libprofile.h and i get the error no such file or directory Is this the exact error message? If it isn't, could you paste the exact error message in your mail? i am using esbox IDE and i installed the libprofile on my scratchbox using the following command apt-get install libprofile-dev and it is installed successfully but when i try to install it in the ordinary terminal it says could not find it what is the problem? Are you using the include file in a shell script? Or are you using it in a C file? Jeremiah -- the exact message is src/main.c:24:24: error: libprofile.h: No such file or directory Have you put libprofile.h in a place that your compiler can find it? Have you passed the compile the include flag? Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: no such file or directory?
On Nov 15, 2009, at 9:10, mohamed ismael wrote: i added the following line in my code #include libprofile.h and i get the error no such file or directory Is this the exact error message? If it isn't, could you paste the exact error message in your mail? i am using esbox IDE and i installed the libprofile on my scratchbox using the following command apt-get install libprofile-dev and it is installed successfully but when i try to install it in the ordinary terminal it says could not find it what is the problem? Are you using the include file in a shell script? Or are you using it in a C file? Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: popularity-contest (was Re: Follow up from QA meeting on IRC)
On Nov 12, 2009, at 6:15, Quim Gil wrote: Hi, ext Edward Page wrote: Which reminds me, any reason Maemo doesn't use Debian's popularity contest? At least at a community level there is https://garage.maemo.org/projects/popcon/ Bas (the founder of that project) and I have been discussing how to implement this. debian's popularity contest is definitely going to be used at the very least as inspiration, but hopefully its code as well. Right now it spends a lot of time trying to determine the last time a tool was used and that may be more relevant to a server environment than a mobile device. What I had hoped to do was to 1. Create a md5 or sha1 hash of the device's MAC addres and IMEI as unique identifier which cannot be tracked back 2. Check which repos the device is using, to see where the software comes from 3. Ask dpkg what is installed 4. Aggregate the dpkg output and rank that, roughly like popcon but perhaps doing some other cool things I want to preserve as much privacy as possible on the device so anyone who participates is not identified. I know that I can only obfuscate data, not hide it completely, so I strongly feel this project should come with the advice that you may not want to use it. It also should not be a Nokia project because it is bad if Nokia is gathering information surreptitiously on its users. So let me be clear: this is a community project that is completely voluntary! Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Follow up from QA meeting on IRC
On Nov 12, 2009, at 9:17, Dave Neary wrote: Hi, Edward Page wrote: To help remind people that there is a checklist and whats on it, should the rating page link to or include the criteria? Yes - that makes sense. I see there were no notes on the algorithm. A threshold of 10 was annoying as a developer. As a tester, a threshold of 10 made me feel more comfortable not doing a full blown /opt check or power management check because of 10 people I could hope someone else would do it and I could worry about other issues like application stability. With a smaller threshold I would feel more of a burden to do all of the steps which would discourage me. Ed's point definitely resonates with me. The great thing about QA is that you can crowd-source it effectively if you don't require much of the user/tester. It seems like the Maemo QA process is more developer-focussed than user-focussed at the moment, and is as such pushing a lot of the responsibility for the QA process to the user. QA is logically the next step after development and is often done by an engineer, at least in the corporate world. Even in maemo, those who do QA so far have also been developers; either they have done QA on their own package or they have done it informally for other's and use the extras-testing interface. In short - the expectation is that you are pretty deep into maemo. This seems like an ideal opportunity to lower the barrier to participation to tiny levels, but only if it is 1. easy to give a +1/-1 Well, we need to keep this distinct from merely rating the package. We are not rating here, we are promoting quality packages. You may be asked to promote a package you think frivolous, but if it meets the technical criteria you are asked to promote it. 2. We don't require intimate knowledge of the Maemo community for feedback (I'm thinking of the checklist, what optification means, etc) Feedback is welcome through a variety of means - rating the package with stars on the download page is one for example. Feedback is welcome in QA too, but let's not pretend that this isn't a serious technical process requiring at least some knowledge of the underlying operating system and perhaps the package system and even how the development process works (on a high level). We need to insure that those who are doing QA, can handle the technical demands so that the software does not damage the device and maemo's reputation. This really does require a clear specification, i.e. checklist, and knowing what optification means in the maemo context. 3. We require enough feedback that most of the code paths in the application will be tested before we OK an application Lowering the threshold to 5 is implicitly saying we're not getting feedback quickly enough, I think it is really saying that the bar is currently set to high. which in turn is saying the feedback process is overly cumbersome for a casual user. Yes and it should be. This is critically important and has serious implications and technical challenges. Anyone at all is welcome, but you may need to learn some stuff about the QA process. The QA process is hard because developing is hard, writing code is hard, integrating into an OS is hard - we need to make sure those things work. It seems to me that that's the problem, rather than the contents of the checklist or the threshold in place. If giving feedback was trivially easy (as it is, for example, in Android Market) you would be getting hundreds of votes when new versions of applications are released, as people installed used them. We need a separate mechanism for this then, perhaps this is similar to the app rating system we already have on downloads? So - how can we make giving the feedback and voting on applications easier? I don't think the idea of Quality Software fits with the idea of Easy to do. Exhibit A: Windows. Many developers are familiar with this saying said to management only half in jest: Quality, Time, Cost - pick two. Seriously, we don't want people surfing by and clicking pejoratively. We need a set of serious technical criteria to assure quality software, not a warm and fuzzy interface where the hoi polloi randomly click shiny buttons. Jereamiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
On Nov 12, 2009, at 4:50, Graham Cobb wrote: On Wed, Nov 11, 2009 at 04:29:55PM +0200, Marius Vollmer wrote: 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. Actually, I disagree. I don't see this field as being anything like a changelog. It is an alternative description to display to someone who already has the program installed and hence, probably, already knows what it does any why they should install it but does not know whether they should bother to install this particular release. So, for a security update it would contain text something like: This is an important security update that should be installed as soon as possible. This is what the changelog was designed for. The control file should not be for messages but rather more like a compiled file that just happens to be text, users should not be reading it. According to debian policy source package control files only have five _mandatory_ fields. This means it is very unlikely that any X-* random header we invent will be used upstream or even downstream, and we are encouraging non-standard control files which may make Mer do non-standard stuff etc. We want compatibility across projects, therefor compatibility of control files across projects. I.e. a package built on Mempis should 'just work' on Maemo, Ubuntu, etc. Bunches of header files in the control file pollutes that namespace and makes compatibility harder, let's use the changelog. For beta-testing releases (releases that will never be promoted beyond extras-testing) I do use it to describe the user-visible changes since the last full release, including bug numbers fo fixed bugs. However, for real releases (which will get promoted into Extras) I use it to give a general view of the release. For example, for a (fictional) 2.7.4 release, the text might read: This update contains many bug fixes since version 2.7, particularly in import and export capabilities. The only change since 2.7.3 is a fix to Edit menu handling in portrait mode. 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. But the audiences are completely different. changelog's are not documentation. They are documentation. Documentation for the builders of the software. Just as the header file is not suitable user documentation, changelogs are not suitable upgrade documentation. I don't agree actually. The user description has to answer the question why should I install this, the changelog has to answer the question what has changed -- the answers are related but are not the same and cannot be generated form the same source. Particularly as the descriptions have to be read in a specific layout in the AppMgr, which is much better suited to a paragraph of natural language text than a detailed list. And don't forget the requirements of translation as well. Well if HAM has a little slug saying Changed frobulation on foo: fixes security hole. that can come from the changelog just as well as the control file, perhaps more easily. Keep the upgrade description. If some people want to generate it automatically from their changelogs that is fine -- I can imagine an mh-generateupdatedescfromchangelog program which can be called from debian/rules. But don't do it automatically. I actually think this method has some potential. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
