Re: [maemo-devel] List emails subject prefix
I have been very concerned about a general tenor of this list. It seems like some are suggesting that if you haven't been on the list long enough, if you don't use the right email client, and several other comments I've heard recently, then you aren't good enough to be on this list. Instead, we need to be welcoming old and new, people using pine, elm, modest, Outlook or whatever email client. While I know that you're referring to other threads as well, and while the responses to Edward's post weren't all as kind or thoughtful as they could have been, it should be noted that subject prefixes are a well-known hot-button topic (on many lists, not just this one). Furthermore, they've been discussed and rejected here: http://www.gossamer-threads.com/lists/maemo/developers/30148#30148 http://www.gossamer-threads.com/lists/maemo/developers/16800#16800 Among the litany of good reasons against subject tagging [1], we have the added reason that screen real-estate on mobile devices is precious and long subject-lines are especially problematic for the many individuals reading this list on small-screened maemo-devices. While we as a community can always aim to improve our tone and focus energies better, I don't think this was a case of jump on the newcomer. It's a FAQ for mailing list administration in general, an AQ for the maemo-* lists, and an issue both sides tend to feel strongly about. With the tremendous influx of new users right now, there are bound to be some growing pains. That's not an excuse for bad-behavior, we still need to police ourselves, but it's worth keeping in mind. S... welcome aboard Edward. Thanks for your suggestion, please consider checking the archives before posting next time because this was discussed already. Cheers, Mike Lococo [1] http://www.andrew.cmu.edu/user/qralston/writing/tagging-harmful/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle won't run on N800/N810?! (was Maemo for commercial development (was Re: N810 RIP) )
Whoa! backup. Would someone else please confirm that freemantle will NOT run on the N800 or N810? This is the first that I have noticed this. I don't have links handy, but as a lurker on planet and the dev-list I know it's been mentioned several times. It's been a while since I've looked at projected specs for the new device, but significantly increased CPU horsepower, hardware 3D, and accellerometers all vaguely ring bells for me, any of which could be deeply integrated into Fremantle in such a way as to make backporting to older hardware a significant amount of work. I don't recall if there was talk about a Nokia-provided hacker edition of Fremantle. I suspect there won't be, as it didn't gather a lot of community development on the 770 and with projects like Mer creating a community-supported build already, I suspect Nokia will focus on getting them the resources they need to improve their offering. Thanks, Mike Lococo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application Manager and Extras-devel: Dealing with unstable software
what can we do to protect users from the full fury of Extras-devel while still giving them reasonable access to some of the stabler applications in the repository? Another ugly trick would be to have dynamic repositories. There be dragons, similarly with a package whitelist for extras devel. By adding another layer of abstraction which is outside of the user's control you're asking for additional confusion when a package that someone wants is masked out by some other package's whitelist/dynamic repo function. If we really want to do this right, look at how Smart Package Manager [1] handles multiple repositories. It uses a combination of: - Repository labeling while browsing for packages, so that when you're looking at a package you might want to install, you know where it's coming from. - Repository preference weights to ensure that packages are always preferred from your stable core repository, even if newer packages are available from less preferred repos. - Package by package preference weights, to ensure that you can resolve any corner cases that arise in repository preferences. - Package pinning, so you can just lock something down from changing if you've got a stable combo for a tricky set of packages. Because App Manager currently deals with a small number of packages (compared to most of the desktop distros, anyway), I think we could get away with simply labeling the repository source in the various package views (but especially the upgrade view) and simply leveraging App Manager's existing capability to upgrade packages one at a time to allow users to pick and choose which ones they want. The Alpha/Beta color scheme could add additional context as to how stable users should expect a package to be, as long as the debtags were compatible with upstream. Thanks, Mike Lococo [1] http://labix.org/smart ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Beware 'Personal launcher'
The answer is not testing of things being put into Extras snip / The answer for the community repository is a feedback mechanism, both for packages themselves, and for contributors. We need to create an easy way for people to provide feedback on the apps they install from Extras and for people to see the feedback level of both the app and the contributor before they install it. Agreed that individual testers gatewaying extras is a bad idea. Some alternate proposals... 1) Require an application to spend some period of time in extras-devel without a major bug submission before promotion. This wouldn't require technical enforcement, just a clear guideline for package-owners to follow. If package-owners behave irresponsibly, the bug-wrangler or some similar role could chastise them and point them to the promotion guidelines. 2) Create a guideline for when a package should be demoted to extras-devel based on negative user feedback. Using the recent personal launcher thread as an example, if an applet really does have a crash/reboot bug, it's filed in bugzilla, confirmed, and ignored for some period of time, that applet probably shouldn't be in extras. That's an extreme example, and in order to prevent frustration the guidelines for demotion must be very clear, and very strictly adhered to. Leaving garbage, buggy, unmaintained apps in the end-user repo is bad juju, but so is pulling well-maintained apps just because they have a serious bug that happens to be found by a high-profile community member (not to pick on Eero who a huge amount of amazing work, but if someone else had found that bug demoting the app would never have been considered at all). Thanks, Mike ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: What category should network filesystems like OpenAFS go under?
Since there's a requirement to use the terminal to configure it, it is no extra step to require the user to use apt-get to install it. snip I don't think we really want to be encouraging people to use apt-get, particularly while apt-get upgrade can break your system. Absolutely agree. While I understand the impetus to save users from having to wade through lots of apps that don't interest them, handling the installation of some applications very differently than others is a non-scalable approach to the problem. But I do think that there should be a category specifically for command line tools so that people who do not use the command line don't have to waste time on them. And I also agree that a GUI configuration dialogue for a system tool is much better than expecting someone to edit a config file. This stikes me as a similarly flawed approach. Terminal-based applications have the same range of functionality that graphical applications have, so you either need to duplicate your category list in two places (and force users interested in both types to look twice), or you stop categorizing terminal-apps altogether (and leave users that use them with the bad categorization problem we have now). Some alternate approaches... - Standard labels: A -cli suffix at the end of each app name would allow users to quickly recognize and skip terminal apps if they aren't interested in them. Even just including a note in the description would be sufficient in my mind. - Debtags-based searches: Give AppMgr a real search facility, and ship canned-queries like graphical apps, terminal apps, etc. - Advanced-Browsing mode: With proper package classification and the existence of extras-devel to hide truly dangerous apps, red-pill (or something similar) could be made into a more discoverable advanced browsing mode that hides end-user apps that are likely to be uninteresting to grandma-types that folks seem so concerned about. Give it a normal preference checkbox, and have it do some debtag or other magic to hide complicated stuff, while making it easy and safe for users who want to see the full range of available software. I do think any binary solution like this which is aimed at hiding apps that are too hard will ultimately prove to be unscalable and unhealthy for the community, which depends on folks discovering challenges which interest them and choosing to learn something new. If the binary filtering is at least easy to disable/ignore, as proposed above, the damage will be minimal though. Thanks, Mike Lococo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: where might this old version be coming from
I'm sorry. I thought extras-devel was a testing area of sorts. Upload something try it out, see how it goes. Then tweak and go through the process again. Then when I'm finally satisfied, promote to extras. But it seems that extras-devel has many of the same rules as extras. Oh well, I appreciate the information. There's nothing peculiar to extras-devel about this rule, it's true of all package management systems. If you fail to update the version information, the package manager on your tablet/other-client doesn't know there's a new version to install and so it doesn't install anything. This isn't enforced by the repo, and the repo can't enforce any different behavior, the client just doesn't know what you want it to do because you haven't told it what you want it to do. Many folks use version numbers like 1.2.3-1, 1.2.3-2, 1.2.3-3 to indicate that each release is of the 1.2.3 version, and only the packaging info has changed (description fixed, files moved, etc). Thanks, Mike Lococo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Documentation for maemo.org Downloads section?
Of course, you might want to keep your repository available for creating packages used by your testers before you want to release to the wider maemo.org community. Is there a reason not to use extras-devel for this kind of thing? Simply upload the experimental packages there with no intention of promoting them until they've evolved/been-updated enough to be ready for a wider audience. Thanks, Mike Lococo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Remove Darius?
David Greaves wrote: As a member of this list I am finding Darius' postings unacceptable for a -developer list. If he continues to post in this manner I would support his removal. Right now there isn't (to my knowledge) any published set of appropriate use guidelines for the list by which one can judge the behavior of any particular member. In the absence of such guidelines, and moderators empowered to enforce them, banning a particular email address seems like bad mojo (not to mention likely ineffective). That said, in the past I've found his posts more inflamatory than contributory and I've killfiled him long ago. I've been much happier since, the whole tone of the list feels much less combative and negative without his posts (I've even left in threads and responses to his posts, which are generally fine without his contributions). My recommendation is to trash his messages without reading them, and don't feed him. Thanks, Mike Lococo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Announcing the Internet Tablet Talk Software Section
Reggie, 1. Developers can optionally list alphas of their apps at itT so users can be notified about them out and suggest features as well as report bugs 2. Developers get it in extra-devel repos 3. Post .install at itT for further discussion as well as Maemo.org downloads I'm afraid that I still don't see the distinction between the itT software section and the Maemo.org downloads section. Maemo/Downloads offers all the same functionality and is in a better position to integrate with Garage, with memo-hosted auto-builder/packaging infrastructure, and with any maemo-extras software taxonomy that emerges (the itT software section has yet another software classification taxonomy that isn't related to any of the other taxonomies in a way that I can identify). The main intention is to make apps more visible to end users and have them join in with the development by providing feedback. This would hopefully help developers more improve their apps as well as offer better IT software to the IT community in the long run. This is an admirable goal, but I think a better way of pursuing it would be to contribute functionality to Maemo downloads and look for ways to integrate the itT community with the developer resources offered at maemo.org, rather than create yet another unintegrated space to watch and monitor for feedback. Thanks, Mike Lococo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Beta Testers needed for a n800/n810 ezine....
Nevertheless, i want to publish an ezine called ATARASHI, specially designed for the n800 and n810 display at 800x480. ... So my question is: please test out this link to see whether the maemo system and n800 specs work out with the flash application i have written: Please take this thread to maemo-users. It isn't related to application or platform development, and so isn't appropriate for this list. Thanks, Mike Lococo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: tracking bugs
We should discuss if is *required* to have a garage package for pushing packages to the autobuilder. This way we have bug tracking, a more direct contact (even for teams)and (the potential for) a far more integrated and simpler system. And there is no real problem in creating a garage page only for packaging, isn't it? This issue has come up as a tangent a lot in this discussion, but hasn't been fully explored so I'm starting a fresh thread to see if it gains any traction. IMO, what is needed is a single garage project and bug-tracker for the extras repo, rather than a separate project for every app in the repo. As much as garage is a wonderful resource for new projects that specifically target maemo, many projects are very much cross-platform and have established developer communities elsewhere. Forcing them to duplicate resources on memo.org isn't productive and isn't necessary. If all the package maintainers are required to have a garage account, and there is a project/bug-tracker for the repo, we get all the benefits that you outline above with much less overhead. I get the impression that folks want to shy away from this solution because it will lead to duplicating bugs that may already have been submitted upstream. The alternatives are clearly worse, though: either requiring upstream to maintain a project presence on maemo.org or requiring maemo.org to integrate with every upstream project infrastructure in the world. I think it's telling that every successful Linux distro in existence uses this model, maintaining a unified project infrastructure for the distro/repo/aggregate-object and coordinating with upstream for bugs that are most appropriately fixed there. Thanks, Mike Lococo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
8) Although I don't think anyone is suggesting that the autobuilder should be an autotester, it could at least install the generated packages into an environment that also has everything else already installed. What kind of conflicts are possible, though? One that I can think of is: - library version 1.1 is built, and published to the repository - application1 is built, with Depends: library = 1.1; build is successful, application1 is published, and the test-install passes - application2 needs library = 1.2, so library 1.2 is uploaded and built; does the system somehow know, at this point, that application1 is now broken? Is this a valid problem, and/or are there other kinds of conflict? This is a problem that can/should be fixed, and should be discovered by the autobuilder. If application1 has Depends: library = 1.1; because an inexperienced package builder didn't know they should be using =, that bug should be fixed. If library genuinely changed something in the 1.1 to 1.2 upgrade that breaks apps, and some apps need 1.1 while others need 1.2, there should be two packaged versions of library that don't conflict (lib-compat-1.1 and lib-1.2). Basically, if there are conflicts in the repo they're bad and the autobuilder should squeal about them. Thanks, Mike Lococo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo security longterm roadmap?
I was maybe not so clear in my last message; What I mean is: We can trust software that come from trusted source and that is 'signed'. But other software, that the end user still want to install can't be trusted. Actually bitfrost is aimed at an entirely different problem than containing third-party malicious software installations. The _only_ solutions to that problem are warnings or disabling third-party software entirely. You _cannot_ install software on your device from untrusted sources and not expect them to be able to abuse your device. Bitfrost addresses a different problem, limiting the effects of exploitation of legitimate software, much like SELinux. From the Software installation section of the document you linked to in your first message: The protection of benign software is a keystone of our security model. We approach it with the following idea in mind: benign software will not lie about its purpose during installation. It's similar to SELinux. It's an interesting idea, although it a _tremendous_ amount of work to write good security policies, and it's also reasonable to wonder about performance costs on a resource constrained device. If you want to see progress made on this front, you should start porting the infrastructure and writing maemo policies for vulnerable apps (like email or the web browser). It's extremely unlikely that Nokia is going to pick up the torch on this one, though, since it's a huge project with very speculative benefits. My suspicious is that it will take several years for this concept to fully bake on the Desktop before it is appropriately applied to resource-constrained devices. Thanks, Mike Lococo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Welcome to the maemo-developers mailing list
Please add me to the mailing-list. I assume you've already received scores of private replies explaining that list subscriptions are not managed by emailing the list, but it's good to have one reply to the list so that folks don't see this in the archives and get confused. You can subscribe, unsubscribe, and manage your list options from this website: https://lists.maemo.org/mailman/listinfo/maemo-developers From the title of your message, I suspect that you are already subscribed, but in either case change requests are managed through the website and not by emailing the list address. Thanks, Mike Lococo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Ideas for Diablo and Elephanta
Graham Cobb wrote: On Monday 24 September 2007 05:14, Quim Gil wrote: Hi, until now we have gathered some ideas about *platform* improvements, but nothing about the *developer platform* itself: are you totally happy about the SDK and the developer tools? Enhancement proposals for repositories, documentation, maemo.org, etc, are welcome as well. One area I find the SDK lacking is support for packaging and releasing. I have spent a LOT of time on working out how best to build and test packages for GPE. My goal is to support all the releases people are likely to have installed and all the devices. I think it's also notable that most packagers don't even attempt this kind of methodical support for each release. I'm not sure if the place to fix this is in the SDK or in a proper build system for garage and the official maemo repository (since after the packages are built consistently the next step is to get them into the hands of users in a consistent way). The lack of an easy way to consistently build packages for all the flavors of maemo in the wild is definitely hurting the platform, though. Thanks, Mike Lococo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Testing applications on the device
[EMAIL PROTECTED] wrote: In which way i can try one of the tutorial's example on my N800? For example i tryed with hildonprogram.c this work inside i386 but if i want try it on device what can i do ? Install xterm and and start the executable from the terminal Thanks , i used the procedure that you suggest using usb cable to transfer executable on memory card and from xterm i tryed to launch but nothing happens. Writing proper thread titles isn't hard, and it is _very_ helpful to people to subscribe to many lists. Please continue this discussion off of this posting, or start another with a sensible title. Thanks, Mike Lococo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: browser on startup
Is it possible to launch on start up the browser in full screen mode? If yes, is it possible to lock the device in this condition? This is a FAQ. There is no bundled functionality to do this for you, and no step-by-step instructions on how to do it manually. However, it may be possible to hack something acceptable together, depending on your specific needs. Start by reading the following post, which gives a high level overview of the tasks that need to be accomplished: http://www.gossamer-threads.com/lists/maemo/developers/22352?search_string=kiosk;#22352 Then search the mailing lists for 'kiosk' to see what others have tried. Then experiment on your own and report your results back. Thanks, Mike ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Excel on Nokia N800
Please could someone tell me what should I download to read excel and word files on my N800, and the give me the appropriate link. I typically work in PDF and text, and so don't have a good answer for your question. I'd like to point out that this thread would be _much_ more appropriate in maemo-users, though. I can't see how it even brushes up against a software development issue. Thanks, Mike ___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
Re: PyGTK CellRendererToggle
I am trying to write a small ToDo app in PyGTK, and though it seems to work fine on my PC, it does not on Maemo. The Checkboxes do not reflect the corresponding values in the TreeStore; instead always the checkbox in the currently selected line is active, while all others are not. Since I am new to PyGTK and Maemo, I might be missing something obvious - could someone please have a look at my code and tell me what's wrong? Actually this is their normal behavior in maemo. You have to set the 'allow-checkbox-mode' property of the treeview to false. See [1]. Ah, that did it. Now it works. :-) There are a number of places where the default behavior of a widget in maemo is different from that of stock GTK. There are bugs filed against many of these misbehaviors in bugzilla, but so far the answer has been that the bad behavior is implemented according to Nokia spec and won't be fixed. It's not a big deal if you're writing an application from scratch (except that it can be confusing debugging across platforms), but does increase the effort involved in porting existing apps. You can find the known bugaboos regarding gtkcellrenderer by searching for it in maemo's bugzilla. Thanks, Mike ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Security Guidance for N800 OS development
This thread should really be put to bed. The only concrete action item that has emerged from it is a request for the inclusion of iptables, which is duly noted. Iptables is one clearly useful tool for limiting access to a daemon based on source IP. Since none of the devices ship with any daemons running by default, this is likely to be a low priority for Nokia engineers. It is, nonetheless, worth noting that it would provide 3rd party developers and and power users with options for limiting access to user-installed daemons. If this is important to someone, they should build a kernel package with the feature enabled. If it generates interest, we'll be in a much better position to petition Nokia for the feature than by discussing it in a vacuum as is currently happening. Thanks, Mike ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] New list spin-off?
I'm ok with the current setup. Maybe just change the default reply-to or i'll always have to use reply-to-all.. Search the lists for reply-to, many people are vehemently against this change. It's not currently on the table for this discussion and if reply-to mangling is to be considered, it should be as a separate and distinct question from the other mailing list changes being discussed. To respond to Quim's question as to whether all this list rejiggering is necessary, I think the answer is no. I've pointed out before, and will point out one last time that application development discussions become API proposal discussions very fluidly and there's a benefit to keeping both discussions in the same arena. That said, if it's decided that there *must* be more lists, app/platform is the most sensible place to make a split. Thanks, Mike ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] New list spin-off?
I think more lists produce more confusion than single one. In fact I'd vote for joining maemo-users and developers as there is no really significant difference in topics posted to them. Developer questions get posted to maemo-users and vice versa and sometimes topics are duplicated since people don't read the other list. The original intention for maemo-developers was for discussing development of the platform itself (think gtk-devel-list) and maemo-users for developing applications to run on maemo (gtk-app-devel-list) We haven't really been pushing people to other lists, though. It may or may not have been a good idea. I would be wary of too much splitting, especially without _very_ clear delineations between the lists. I wouldn't suggest creating more than three areas, one for end users, one for application developers, and one for platform developers. But I think two lists is even more appropriate. Application development questions often evolve into platform api discussions and bug reports, and the line between the two is fluid. Mainly, I think people need to be meaner on maemo-developers about pushing non-development discussion over to the users list. Thanks, Mike ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Unreliable Large Network Transfers
Hi Folks, I'm finding that large (200MB) transfers of data via the wifi network are extremely unreliable. Are you sure network is a problem? Are you writing data somewhere? Both MMC card and iternal flash are really slow when writing. This is the issue. I can reproduce both the slow write speed (~150KB/s) and the GUI unresponsiveness with (from memory, please forgive any typos): dd if=/dev/zero of=/media/mmc1/test.file bs=1M count=250 which doesn't involve the network at all. I may do some playing with multiblock write kernels at this point, although it's not so much the (average) speed that's the problem. I think the real issue is that the CPU doesn't seem to be able to service requests from other subsystems in a timely manner once the write cache fills up. Userspace programs are getting regularly starved for CPU time for several seconds at a time, which causes the wildly fluctuating transfer rates, the unresponsive GUI, the Unison sessions dropping, and possibly the reboots (as programs aren't responding to the watchdog promptly?). The Unison failures, in particular, are disappointing. It is such an awesome program for syncing the 770 to a desktop system, but if you have a large MMC (and you change its contents regularly) it isn't usable at all. Thanks, Mike ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Should I change my Repo's settings?
So, should I had another instance for the maemo repos (maemo and extras) withe the scirocco distro or should I just change the existing ones (mistral) to scirocco? i.e.: If I add a new instance for the same repos with diferent distro (scirocco) - will it break the device? I don't manage any repos and you're getting outside my realm of expertise. My expectation is that you shouldn't need both mistral and scirocco selected, and that doing so might break things. The way it _should_ work is that you should select the dist that corresponds to the OS image installed on your device. Folks using 2.01.2006.26-8 should select mistral, folks using 2.2006.39-14 should select scirocco. Since that's not always possible, I've been selecting the correct dist (scirocco for me) when it is available, and mistral when that's all there is. This has been working well for me. It is always possible for a bad repo to bork your device but many folks are using the config described above and will report such breakage as a bug. I am confised. Does 2.2006.39-14 = scirocco? http://maemo.org/maemowiki/CodeNames Thanks, Mike ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Should I change my Repo's settings?
Hi Folks, Should I change all mistral occurrences to scirocco? My questions is a general one - not specifically for the Canola install. If you have IT2006 v2.2006.39-14 installed... snip good advice about repo settings There is no good general answer for this question yet. What I've been doing is checking the repo to see if they have packages available for scirocco and using those if they do. You can check if a scirocco dist is available by visiting the repo URL in your web browser and going into the /dists/ directory. For example, repository.maemo.org is: http://repository.maemo.org/dists/ The only repos I've found that currently offer scirocco packages are repository.maemo.org, maemo.org extras, and the canola repo. Tableteer, for example, does not... although they do offer a bora dist (ooh, ahh). Thanks, Mike ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
