key_id
Hi, I'm trying to follow the directions at http://maemo.org/community/application-catalog/extras_repository.html. Step 6 lists: debsign -k .changes debsign -k .changes What key is this? The public key that corresponds to the private key in the following step? The PGP key? Is there a page that details the ssh and pgp key requirements? thanks, Frank ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: policy: maemo packaging policy -draft
Yes, that is why I have created several new menus. Once that actually make a little sense. It is then easy to select them instead of Extras. -- Allen Brown http://brown.armoredpenguin.com/~abrown > > Hi, > > Allen Brown wrote: >>> * Interactive prompts from maintainer scripts (such as asking where >>> do you want to stick this new thing in your menus) are annoying for >>> the user. I'd be inclined to add a sentence or two saying that these >>> SHOULD be avoided where possible. >> >> Speaking as a user, the *lack* of asking which menu this belongs >> under is annoying. Stuffing all add-ons into Extras sucks. I want >> my tools organized according to uses, not according to which person >> developed them. > > Personally, I would vastly prefer a system like .desktop files where the > developer says what categories the application is in, and it gets placed > in the relevant menu(s). I don't like having to enter a menu name for, > say, a game, when it should obviously go in the (non-existent) "Games" > menu. > > Cheers, > Dave. > > -- > maemo.org docsmaster > Email: [EMAIL PROTECTED] > Jabber: [EMAIL PROTECTED] > > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: policy: maemo packaging policy -draft
Hi, ext Marius Gedminas wrote: > On Wed, May 28, 2008 at 10:32:22AM +0300, Eero Tamminen wrote: >> A draft version of the "maemo packaging policy" is available >> for commenting: >> https://maemo.org/forrest-images/pdf/maemo-policy.pdf >> >> If you're packaging software for maemo, please take a look at it. > > * Testing on a device with no extra packages is a hard to do, unless > you have two devices, or you're not actually using the one you have. Maybe this would be better: As a result, package installation and uninstallation MUST be tested (also) on the device, before the package is uploaded to the repositories. Test device SHOULD NOT have extra software installed. > I wish we had a complete hardware emulator so that you could test > package installation on a pristine rootfs in a virtual machine. Qemu got recently some preliminary N8x0 support: http://svn.savannah.gnu.org/viewvc/trunk/Changelog?revision=4490&root=qemu&view=markup I haven't tried it myself. In theory the better package dependency / Busybox testing should be possible on Desktop & x86 too, but there's no ready made maemo x86 image that one could boot in x86 system Qemu. > * Interactive prompts from maintainer scripts (such as asking where > do you want to stick this new thing in your menus) are annoying for > the user. I'd be inclined to add a sentence or two saying that these > SHOULD be avoided where possible. Along with selecting sensible defaults so that if/when the GUI tools will support non-interactive mode like the Debian tools do, the package wouldn't do anything stupid. Debconf support is not currently planned though. > * Splitting translations has a question about Debian/Ubuntu. I'm not a > developer of either, but as far as I know Debian ships translation > files for all languages in the same .deb that contains the software, Which has the drawback that translations are tied to the software updates... > while Ubuntu collects all translations from a big group of related > packages into a language-pack-$group-$languagecode, so you end up > with language-pack-lt, language-pack-gnome-lt, language-pack-kde-lt > and so on. Which at least earlier had the drawback of forcing Thunderbird, Firefox and OpenOffice installation on Kubuntu... > The Ubuntu solution is only possible because they release > the whole stack at once. > >> As stated in the policy document, the comments and questions on this >> policy should be mailed to the maemo-developers mailing list with >> word "policy" in the subject. > > This thread qualifies. ;-) Sure. :-) Thanks for the feedback! - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: use of Glade for N810
U can also use Glade directly on your n810 :) Pierre Amadio a écrit : Hi there. On Mon, Jun 09, 2008 at 12:09:13PM +0530, Arvind1 K wrote: Can I use Glade to design my GUI so that it works in the hildon program. I want my application to work by simple tapping by stylus. I have my application written in GTK+, how do I make it work in N810? It should work. See the following url for an example of "hildonization" of an existing application that use glade. http://maemo.org/development/documentation/how-tos/4-x/maemo_4-0_porting_guide.html If my application works in scratchbox, does it ensure it will work in N810? I think it does Good luck. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- Benoît HERVIER http://khertan.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
saying hello to Hildon
Hi guys, So I'm starting to go through the tutorials and how-tos to familiarize myself with how maemo is stacked. I was thinking about improvements to the interface experience and I'm wondering if it would be possible to at all experiment with a port of Enlightenment as the window manager to take advantage of their libraries for effects as it is also a lightweight window manager. Secondly I was wondering if anyone has experimented with porting compiz fusion. I don't know what this would take, perhaps hacking down the size. I'd like to see things get much more "fluid" feeling and elegant, reducing clicks and providing appropriate audio and visual feedback to the user that helps generate a pleasant experience on such a small screen. Also, are there any nokia n810 modders out there? I'd love to see what some people have done. I'm considering looking into the possibility of adding a second screen to mine if it's possible and changing around the ports and buttons. I'm getting my fabrication kit set up so pretty soon I'll be able to make custom plastic forms. Hopefully within a few months I'll have something to show. I also sent out an message to the list that had an image attached, a mockup. Can whoever is moderating release it to the list? It has a cool example of an interface that I made for the Mixxx.org project if a port was made for Maemo. It's mostly inspiration for any maemo hackers out there that would want to work with Mixxx.org to get a port made and tested. Touch-based DJ mixing is already here, on your maemo tablet. Cheers, Paul ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Correction to Maemo 4.01 installation instruction
On pe, 2008-06-06 at 10:09 +0300, ext Wellu Mäkinen wrote: > installation instructions at http://tablets-dev.nokia.com/4.0.1/INSTALL.txt > seem to be updated to reflect few problems that are present at least in > Ubuntu systems. That's what happened. The installers received some additional checks also. > There is one caveat though which should be clearly noted: > > "2.3 Known limitation of scratchbox" states that e.g Ubuntu Hardy users > should > disable vdso and also lower the mmap_min_addr. The problem is that > mmap_min_addr is only present in very recent kernels. If this is set in > earlier kernels they simply die during boot. > > Ubuntu Hardy is ok with this but Gutsy gets nuked if you set this in the > sysctl.conf. Actually, we couldn't reproduce this problem with Ubuntu Gutsy. We tried it with a fresh install and one upgraded to the latest versions. If the mmap_min_addr wasn't supported by the kernel, it just got ignored. However we found that the vdso_enabled had a default value 2 and changing it to anything else caused the kernel to hang completely. > So, please add a warning or note that people just don't blindly set these in > their sysctl.conf. Warning has now been added. Thanks for the feedback :) -- Janne Johansson <[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: maemo Bug Jar #6
Am Freitag, den 30.05.2008, 15:07 +0300 schrieb [EMAIL PROTECTED]: > 2. training users while resolving bugs as duplicates > 3. an introduction to watch lists and interest areas. > (that's a general version of bugzilla.mozilla.org's front page link for > "bugs filed today") We may want to set up a "Triage Guide" wiki page with an introduction and guidelines for triagers and reporters (in fact these are two different target audiences and may result in two wiki pages). E.g. GNOME always asks new triagers to read http://live.gnome.org/Bugsquad/TriageGuide first. http://wiki.mozilla.org/MozillaQualityAssurance:Triage is also a good source. And timeless pointed me to http://browser.garage.maemo.org/news/8/ . I have this on my todo-list and plan to come up with a proposal that should be discussed with the triagers community that we have. Of course, if anybody wants to go ahead with a draft/first version, feel free to do so! :-) andre -- Andre Klapper (maemo.org bugmaster) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: use of Glade for N810
Hi there. On Mon, Jun 09, 2008 at 12:09:13PM +0530, Arvind1 K wrote: > Can I use Glade to design my GUI so that it works in the hildon program. I > want my application to work by simple tapping by stylus. > I have my application written in GTK+, how do I make it work in N810? It should work. See the following url for an example of "hildonization" of an existing application that use glade. http://maemo.org/development/documentation/how-tos/4-x/maemo_4-0_porting_guide.html > If my application works in scratchbox, does it ensure it will work in > N810? I think it does Good luck. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo Bug Jar #7
Am Donnerstag, den 05.06.2008, 10:54 +0200 schrieb Luca Olivetti: > It's useful to know that a bug is fixed, what isn't useful is that the > fix isn't actually available Quim already answered this partially, let me also try to describe our bugmaster's point of view here. We could create new statuses in Maemo Bugzilla, for example "fixed in codebase" and "fix publically available to end-users by updating through the official software channels", but I don't see much sense in that. I expect bug reporters to update their software from time to time to check whether their issue has really been fixed - it's a question of how much the bug reporter wants to be involved in the process (some people just want to file bugs and don't care about verifying the fix, while others have the will and motivation to verify. It's their personal freedom to choose their grade of involvement). In GNOME Bugzilla (that I have been working on for several years now) bugs also get closed as fixed when the fix has been committed into the codebase. This often means that "average" end users cannot immediately verify the fix (except they are advanced users/devs compiling from SVN source). We expect them to reopen the bug after they have been able to verify that the commit did not fix their issue (which could be months after closing the report as fixed if they only run stable versions shipped by their distribution). This is a question of policy, but I cannot see good reasons to make this more complicated for everybody by adding more statuses here. I'm sorry to say, but this is how code development generally works from my point of view. I may be wrong here, but it has worked out well for me so far. andre -- Andre Klapper (maemo.org bugmaster) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo Bug Jar #7
[an off-topic posting about fixed release dates. please stop reading if not interested.] Am Freitag, den 06.06.2008, 19:48 +0200 schrieb Krischan Keitsch: > Quality first! Releasing shouldn't _only_ be a management decision. When the > quality is as expected then the (scrum ?) team should hand over the > responsibility to the management. They can then powerpoint the great > event ;-) > Personally I consider fix release dates as contra productive. Quality it the > key to success. Depends on the kind of project and your customers. >From my point of view GNOME has also become successful because they were one of the first projects that started publishing based on a predictable schedule (a new major release every half a year). This worked out quite well in the past (though the latest GNOME release, 2.22, was a pretty risky one), and other open source projects have also started to publish schedules (e.g. KDE 4 - no flamewars, please). Customers (=distributions) can reliably plan which version to include and start beta-testing the release candidates of the final GNOME version they plan to include. Fixed release dates can create some pressure to get things done, especially in open source projects that aren't steered by *one* company that pays you (and in worst case could fire you), because you have way less tools to create pressure and motivate volunteers. :-) -andre (GNOME Release Team member) -- Andre Klapper (maemo.org bugmaster) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder for maemo extras repository
Neil Jerram a écrit : > 2008/6/6 Fred <[EMAIL PROTECTED]>: >> Looks like it works ... >> >> Can this pb be linked to the fact that I have a passphrase associated >> with my ssh key and that I may not answer the passphrase question as >> soon as it arises ? > > If that is the problem, are you aware of ssh-agent and ssh-add? > > Neil Thanks a lot : it's exactly what I wanted, I love learning ;) Fred ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder for maemo extras repository
On Fri, 2008-06-06 at 15:31 +0200, ext Fred wrote: > Hi, > > I try to be able to generate my projects for OS2007 as well as 0S2008 > (with a few lines in configure.ac) > > But with the auto-builder, I have to specify hildon dev packages in > debian/control ... which breaks my setup for OS2007 > > What would you recommend to keep this possibility ? > Alternative Build-dependencies should help you in this case. You can read about them here: http://www.debian.org/doc/debian-policy/ch-relationships.html In short: You can specify both OS2007 and OS2008 packages as a build-dependencies. Something like this: Build-Depends: hildon-fm-dev | libhildonfm2-dev, libosso-gnomevfs2-dev | libgnomevfs2-dev But, considering the fact that hildon API was broken between OS2007(bora) and OS2008(chinook)[1] I'm quite sure that this change isn't enough to compile package for both platforms. [1] http://maemo.org/news/announcements/view/1184675758.html -- Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder for maemo extras repository
On Fri, 2008-06-06 at 19:10 +0100, ext Graham Cobb wrote: > On Friday 06 June 2008 14:22:33 Niels Breet wrote: > > > On Fri, 2008-06-06 at 13:56 +0200, ext Niels Breet wrote: > > This is because we process the queue every certain amount of time > > and we check if we have seen the file before in the last run. > > > > A file that has been there for a certain amount of time gets > > processed. > > > > > > Ed: Do we need to make the upload_timeout a little longer? > > >>> > > >>> Yep. That's what I'm thinking of. What is the current value? > > >> > > >> 180, so that is pretty low. As it must at least be the time between 2 > > >> queue runs? > > > > > > It's 3 minutes. Not that low, I'd say. Let's set it to 240. If it's > > > still not enough then we can increase it even more. > > > > I have set this to 240 now, let's see if this is enough to solve the > > problem. > > Do I understand this correctly? You are saying that if I upload a package > and > the autobuilder runs fewer than 4 minutes after I do the upload, that the > files will be ignored? So, I may have to wait 9 minutes before the build > starts? > It's not that bad, don't worry :) If .dsc file is in incoming directory autobuilder will always try to pick it up. If some problems with file found then autobuilder will skip it if file is sitting there less than timeout value or will reject it in opposite case. > ___ > 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: policy: maemo packaging policy -draft
Dnia Sunday 08 of June 2008, Allen Brown napisał: > > * Interactive prompts from maintainer scripts (such as asking where > > do you want to stick this new thing in your menus) are annoying for > > the user. I'd be inclined to add a sentence or two saying that > > these SHOULD be avoided where possible. > > Speaking as a user, the *lack* of asking which menu this belongs > under is annoying. Stuffing all add-ons into Extras sucks. I want > my tools organized according to uses, not according to which person > developed them. control panel allows You to organize this menu in any way you want. With crap called Application Manager where you can install just one application at time asking used is 'acceptable' but when I install packages using apt-get it is really annoying to check why does installing halted which happens when apt-get is called from remote shell and application asks where do I want to have it. With those 'finger-but-not-user friendy' style menus putting everyting into Extras has sense. -- JID: [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: policy: maemo packaging policy -draft
Hi, Allen Brown wrote: >> * Interactive prompts from maintainer scripts (such as asking where >> do you want to stick this new thing in your menus) are annoying for >> the user. I'd be inclined to add a sentence or two saying that these >> SHOULD be avoided where possible. > > Speaking as a user, the *lack* of asking which menu this belongs > under is annoying. Stuffing all add-ons into Extras sucks. I want > my tools organized according to uses, not according to which person > developed them. Personally, I would vastly prefer a system like .desktop files where the developer says what categories the application is in, and it gets placed in the relevant menu(s). I don't like having to enter a menu name for, say, a game, when it should obviously go in the (non-existent) "Games" menu. Cheers, Dave. -- maemo.org docsmaster Email: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
