Re: scratchbox ide
2009/1/20 Frank Banul : > > I'm curious what development tools you use? Textedit is nice and all but I'm > sure that there are better tools. I would be interested in an editor that > supported more code oriented tasks. Any suggestions? Emacs? I have pretty extensive code-oriented needs, and it meets all of those (and more). Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal for Diablo's authoritative list of package categories
2008/10/29 Andrew Flegg <[EMAIL PROTECTED]>: > On Wed, Oct 29, 2008 at 10:40 AM, Neil Jerram <[EMAIL PROTECTED]> wrote: >> > [snip] >> >> Agree with all that. However, if "Programming" is a better English >> term than "Development" - which I agree with - surely the section name >> should be "users/programming"? > > Why, though? Because it's a clearer word, for the developer looking at what to put in his/her Section: header... > The "technical English" keys better map to upstream. ... but OK, I can see that that's a good argument for not making not-especially-compelling changes. > There's no reason we *can't* change it, but what's the advantage? The > main point I'm trying to get across is that the English translation is > no more special than any other language. (I'm not disputing this.) Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal for Diablo's authoritative list of package categories
2008/10/29 Andrew Flegg <[EMAIL PROTECTED]>: > 1) "Consistency" - with what? Why is consistency between the package > maintainer's key and the displayed text /in one language/ > important? > > 2) These are *example* English versions. Further discussions have > resulted in other suggestions, like: > > user/multimedia Sound & Video > user/navigation Location & Navigation > user/utilities Accessories > user/networkInternet & Networking > > These strings are just that: examples. They are to demonstrate and > further illustrate the applications which should go into each > category. Once the category list is finalised, the translations in > English, French, German, ... can be determined. Agree with all that. However, if "Programming" is a better English term than "Development" - which I agree with - surely the section name should be "users/programming"? Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo & Linux mainstream (was Re: Projects Nokia should support (yours?))
Hi Quim, 2008/10/24 Quim Gil <[EMAIL PROTECTED]>: > Thanks for the very good feedback! > > Answering to Till and Neil, who came up with requirements difficult to > combine: mobile uniqueness versus API compatibility across several > platforms. Many thanks for your response. It is clear that you understand and are trying to incorporate the point/viewpoint that I was expressing, so thank you for that. Also I appreciate how the overall problem that you are trying to solve is more difficult than mine: you are trying to work out how to promote and sell new products, whereas I am trying to maximize the benefit of my free software time. (And I could be right to suggest that maximizing community benefit is a path to commercial success, but I could equally well be wrong; I just don't have the experience to know. In my free software project there are similar issues: with limited resource, should we concentrate on fixing bugs, and working on specific things that people report on the mailing list, or should we ignore those and work on big sexy new features? I don't yet know there either!) Just a couple of further comments below... > The problem is not that much on the performance side. Performance is of > course a problem but in our opinion not as big as the differences in use > cases and UI requirements for a small touchscreen. I completely agree that the UI requirement differences are very challenging. I just don't think that we have yet fully explored the possibilities for addressing this within the infrastructure, as opposed to by modifying application level code. I'm thinking of things like transparent, overlaying, application-specific keyboards; pervasive and easy ability to zoom and pan what you are seeing on screen; arbitrary mapping of available hardware buttons to input events that make sense to applications; and so on - by definition this list is not complete. > I don't know developers not willing to produce software that users find > amazing and fall in love with. Ok, in fact I know some ;) but you get > my point. I do. But I'm worried you're missing amazing applications that already exist. As well as supporting new development, what about asking for recommendations of existing apps that would be great on the tablets, with a little polish? >> (Note that "writing" here includes activities like packaging. In an >> ideal world, I would only have to package each new version of my >> software once, upload the source package to Debian, and everything >> else would follow from that. Note that this has now been achieved for >> the Openmoko phone, so it is entirely possible.) > > Even if it's technically possible, there is something no technology > solves (at least nowadays): the use cases for someone in the move with a > device in their pockets are different from someone sitting with a > computer on the table. For many apps just this is critical. Yes, but I think the Debian people would say that they want to include mobile stuff too, not just desktop. Hence (1) there may already be suitable mobile apps there; (2) even if not, it would still (I think) be a good distribution channel for future mobile apps, plus infrastructure needed for them. >> - the existence of hildon. > > Hildon is available in Debian and Ubuntu. That's good, sorry for not checking that myself first; it means I should be able to push my hildon bindings upstream too! > It covers features important > in the mobile context that GTK+ is not covering as for today. I hadn't appreciated that, through just using the widgets. Is there a write up of this somewhere? Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Projects Nokia should support (yours?)
I sense two fundamental problems here. 1. You (Quim) are looking for applications that will help differentiate the next Internet Tablet. But differentiation is contrary to the interests of the majority of the community. 2. The timescale is too short. Either people already have most of their time committed for the next few months, or they don't. I would venture that those with time on their hands are mostly unlikely to be people who could pull a project together in this timescale, and to the quality that you are looking for. (2) is self-explanatory. To expand on (1) a bit... My time for free software is limited, and the best outcome for me is if I can use that time to write something once, and then have it automagically show up and run on the widest possible set of devices: my computer, internet tablet, phone, and so on. (Note that "writing" here includes activities like packaging. In an ideal world, I would only have to package each new version of my software once, upload the source package to Debian, and everything else would follow from that. Note that this has now been achieved for the Openmoko phone, so it is entirely possible.) So, for me, anything that requires me to "port", or to do something differently for the Nokia tablets, is a negative. A couple of specific examples are - the /var/lib/install thing in the first 770 OS ... thankfully now long gone - the existence of hildon. And so here are a couple of project ideas. 1. Work on a Gtk+ theme, and changes if needed to the upstream Gtk+ project, so that any existing Gtk+ app will run (without any porting) on the tablet and look as good as hildonized apps do today. 2. Organize the system so that the Debian arm repository can be used as is. If you did that, there would be 100s of existing apps that would run and look good - which for me would be a far more powerful selling point than one or two specific applications written specifically for the tablet. I hope that's useful. I appreciate it will probably come across as an extreme viewpoint, and perhaps I should spend more time before sending to try to develop a more reasonable intermediate proposal - but I don't have time for that right now. Best wishes, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: ALSA sound driver for Nokia 770 and DSP programming
2008/9/27 Siarhei Siamashka <[EMAIL PROTECTED]>: > > That's great, feedback is very much welcome. Though bugreports can wait until > I roll out the next revision of the patch ;) Well then I will also say that I think your progress on this is great, and that I enjoy reading your emails, even if I have nothing to contribute to them. I have two 770s, and this work will help them to be more useful for longer. I love it when you write that something is difficult and needs more work... then I just know that you will have done it about a day later! Best wishes, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: programming on the n800 itself
Hi Hendrik, 2008/9/23 Hendrik Boom <[EMAIL PROTECTED]>: > > Does anyone know which system component uses guile? I've done guile stuff on the 770 and N800, including preparing packages for core Guile, g-wrap, slib and guile-gnome. I've lost track of what the latest status of those is, but I'll try to work it out and get back to you. I believe that core Guile, including the library and command line interpreter, may be available in the base maemo repository, and so installable with apt-get. The card game aisleriot uses Guile, so if you install aisleriot it'll pull Guile in too. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [Make.am issue]Sofia throuwing Error message
2008/9/8 Dave Neary <[EMAIL PROTECTED]>:
> This happens when you do something like this:
>
> #include
> #include
>
> struct test *t;
>
> int main(void)
> {
> t = malloc(sizeof *t);
> printf("%d\n", t->i);
>
> return 0;
> }
> In the above example, adding
> struct test {
> int i, j;
> };
>
> before the declaration of t fixes the problem (but creates a different
> runtime problem - a virtual cookie for the person to see the issue).
t->i being undefined?
Neil
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 770 info in wiki Re: Has maemo-pc-connectivity been substituted by USB Networking applet (in control panel)?
2008/7/5 Dave Neary <[EMAIL PROTECTED]>:
>
> I speak not as a representative of Nokia, but as a documentation
> editor/organiser.
>
> One basic rule imposes itself: documentation should be useful to its
> reader. There's an eternal balance between "give the user the
> information he needs" and "be as complete as possible".
>
> Wiki pages where 10% of the information is useful to an OS2008 user
> ("Install package X") and 90% is useful to a 770 user ("Edit file Z, as
> root run "insmod Q", ...), then we need to make the page as simple as
> possible for the majority of our users (N800 + N810 users), and ensure
> that the "first principles" information is available to a 770 user,
All agreed with you up to here.
> but
> isn't in the same place as the useful information for the majority.
>
> That means that you have a first page targeted at OS2008 users, and a
> second page targeted at "legacy systems", which is in an appropriate
> category. The second page will *only* get linked to from the first page,
> and won't show up in your normal wiki navigation.
But the rest is arbitrary. I see no need for separate pages, only
clear section headings within the page.
>> Please be careful with removing
>> 770/OS2006 or 2007(HE) information. Also people still use N800 with
>> OS2007, latest in not always greatest :-)
>
> Often, the first step for someone who has a problem with an N800 and
> OS2007 is "first, upgrade to OS2008". There was a time in my life when I
> didn't like throwing anything away, but as time has gone on, I realise
> that you have to make a choice. Some things you keep close at hand or
> put on the mantelpiece, some things get tidied away in boxes for the day
> when you might need them, and some things just have to go.
That is you making a choice for yourself. In the current discussion
about wiki content, the debate is whether your proposal is best for
the whole community, some of whom will have made different choices;
not just for how you use your ITs.
Regards,
Neil
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: command line mplayer under OS2007HE - basic shell scripts to run audio or video
2008/6/30 Darius Jack <[EMAIL PROTECTED]>: > Hi, > > installed, upgraded mplayer and can run it with GMPlauncher > and looking for some basic shell scripts to run mplayer from command line. It sounds like you're looking for mplayer's "slave" mode. > Please refer me to a nice place with some examples of shell scripts. I'm afraid I don't have any such scripts or links myself. Googling for "mplayer slave" may give you some starting points, though. Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Garage Misconfiguration?
2008/6/19 Benoît HERVIER <[EMAIL PROTECTED]>: > > It look like s there is one email by project :) I've received 4, at intervals of 1 hour, and I believe I only have one Garage project. The last one was about 21 hours ago, so it looks like the problem is solved now. Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Fwd: Community council is a representative body - not community leadership
2008/6/16 Allen Brown <[EMAIL PROTECTED]>: > What clearly won't work is to try to reason with him. That's like > trying to reason with a scorpion. The odd thing, IMO, is that usually when someone like this crops up on a forum or mailing list, it's pretty clear what their agenda is, or where they're coming from. With Mr. Jack, I must confess that I have no idea whatsoever what his point or angle is, despite having (at least half-) read several of his posts. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: correct kernel source for RX-34_2008SE_2.2007.50-2 ?
Frantisek Dufka <[EMAIL PROTECTED]> writes: > inode0 wrote: >> If the alternative is to not get new firmware released until later >> when source is ready to go at the same time I think getting firmware >> as soon as possible and showing some patience while waiting for the >> source is the preferable arrangement for most users. I suppose not >> everyone sees it that way though. > > Yes, not everyone sees it that way :-) It also reveals a cultural or management failing at Nokia. Such steps (making correct source available) should be properly planned into the development process. Once you do that, you'll find that they don't actually take any significant time. We hear endless talk of lawyers when it's a matter of why Nokia can't make their media player (file manager, application manager, etc.) open source. Why are the same lawyers not so hot on making sure that legal obligations are met w.r.t. the kernel code? Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Ogg Vorbis / Theora Language Removed From HTML5 Spec
"vicente garcia" <[EMAIL PROTECTED]> writes: > Subscription required I'm sorry, I should have flagged that upfront. (But I'd guess that a fair number of maemo-developers are LWN subscribers, so hopefully my post is useful for them.) Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Ogg Vorbis / Theora Language Removed From HTML5 Spec
"vicente garcia" <[EMAIL PROTECTED]> writes: > WTF? > > http://yro.slashdot.org/article.pl?sid=07/12/11/1339251 See http://lwn.net/Articles/261694/ for a good appraisal. Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: App catalog (was Re: extras: autobuilders)
[...apologies for this very delayed reply...] Quim Gil <[EMAIL PROTECTED]> writes: > On Mon, 2007-11-12 at 20:16 +0000, ext Neil Jerram wrote: > >> There's an interesting meta-point, also. The current existence of the >> Application Catalog partly (largely?) reflects the fact that not all >> 3rd party apps are in extras. > > I see (almost?) no relation. Just to be clear, I guess I was assuming/describing my own preferred way of working - i.e. that if an application appears (following a refresh) in the Application Manager list, I would see no need, if I already knew what it was, to go and check it out in the App Catalog; I'd just install it using Application Manager. However, I can see now that the App Catalog can also have useful other purposes, for marketing and as a central point for accumulating feedback etc.; thanks for pointing that out. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: installing .deb to N800
Tripti Gupta <[EMAIL PROTECTED]> writes: > It is like: > > (Reading database ... 16712 files and directories > currently installed.) > Unpacking myapp (from myapp_1.0_armel.deb) ... > dpkg: error processing myapp_1.0_armel.deb > (--install): > corrupted filesystem tarfile - corrupted package > archive > Errors were encountered while processing: > myapp_1.0_armel.deb > > I simply make .deb in my sratchbox and take the file > to N800 and try installing it by dpkg or even clicking > on it. Doesnt work but same file works for my SDK! Just a wild guess: did you use FTP in ascii mode to transfer the .deb on to your N800? If so, try doing the transfer again with binary mode. (If not, how did you transfer the .deb to your N800?) Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Install failure of maemo-sdk-install_4.0.sh
Micke <[EMAIL PROTECTED]> writes: > Err http://repository.maemo.org chinook Release.gpg > Temporary failure resolving 'repository.maemo.org' > Failed to fetch http://repository.maemo.org/dists/chinook/Release.gpg > Temporary failure resolving 'repository.maemo.org' As it says, this is probably just a temporary outage. Is it still happening if you try again now? If it is, there may be an IP routing problem on your PC. Are you able to ping repository.maemo.org? Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
"Tim Teulings" <[EMAIL PROTECTED]> writes: > Hello! > >> 6) If it doesn't already exist, an entry in the Application Catalog is >>automatically created, including .install file(s) for all supported >>OSs. > > The relevant information must be available in the source/binary package. Well the information for a skeleton Application Catalog entry is already in the package, isn't it? In order to create a bit of HTML and a clickable .install file, all that is needed is the package name, short and long descriptions. >Also I'm not sure if thats worth the effort (or at least this does > not have highest priority). At least I would not put screen shots into > my package to get the application catalog entry build automatically ;-) Yes, definitely screenshots should not go into the package. In that case I guess it would be nice if the basic AppCatalog entry was autogenerated, and could then be enhanced by hand. There's an interesting meta-point, also. The current existence of the Application Catalog partly (largely?) reflects the fact that not all 3rd party apps are in extras. Perhaps if almost all apps were in extras, and the AppManager UI was improved to cope better with large numbers of available packages, there wouldn't be much need for the Application Catalog any more? Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Ed Bartosh <[EMAIL PROTECTED]> writes: > On Mon, 2007-11-12 at 00:03 +, ext Graham Cobb wrote: >> >> Let's assume, for a moment, that Nokia introduces a V4.1 that updates both >> libhildon1 and libhildonfm2 to new versions. I presume Nokia would test the >> old versions of the libraries together, and the new versions of the >> libraries >> together but would not expend testing effort on testing the new libhildon1 >> with the old libhildonfm2. And assume that there is actually a bug and the >> old libhildonfm2 doesn't work correctly with the new libhildon1. >> > In this case I'd suggest to put both libraries to extras-devel and > tested for upgradeability together with applications. If some issues > will be found bug will be failed and hopefully fixed. Fixed library will > be uploaded to extras-devel and later to extras. Case solved. One general (and inexpert) thought on such problems: it may not be possible to avoid all possible conflicts and breakages before they happen, but so long as such problems can be quickly fixed once they're noticed, that may be good enough. Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
Simon Pickering <[EMAIL PROTECTED]> writes: >> Then there are (probably obvious) things about the detailed operation >> of the above points, like automatically emailing the uploader if a >> package doesn't build. >> >> If possible, it might make sense for the interface to the auto-builder >> to be integrated into garage. >> >> - It feels reasonable to say that a project must have a garage page, >> in order to use the auto-builder. > > What about the myriad libraries that will be added to build all the > random apps we want? Would each of these need a Garage page or could > they all be grouped under the same page? I imagine most of these will > be simple modifications (if they even need that) of existing debian > packages and therefore a Garage project is probably overkill, a > maintainer's email address ought to be enough. Good point. I take back my statement for now, then. (I quite liked the idea of the auto-builder reporting build problems through a garage bug tracker, though.) Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
Graham Cobb <[EMAIL PROTECTED]> writes:
> I would add a few things to Andrew's list in the area of dependency
> management
> as this is a subject dear to my heart! GPE consists of 7 user visible
> applications comprising a total of 30 packages with complex dependencies
> between them plus some non-GPE dependencies not in the standard Nokia
> repositories (like libsoup and libsqlite0).
I'm not an expert on dependencies, but some comments anyway...
> 5) Dependency aware. At a minimum the build system needs to be dependency
> aware: for example if an application and a library dependency are both
> updated, build the dependency first and then the application.
Doesn't this just happen anyway? According to my understanding...
- If the library is a build-dependency of the application, and the
right version of the library hasn't been uploaded yet, the attempt
to build the application will bail out immediately. On the next
build timer pop, if the library has then been uploaded, the
application build will proceed.
(Perhaps uploading the library could cause the application's build
timer to pop early, but that's well into icing-on-the-cake
territory, not a basic need.)
- If the library is only a runtime dependency of the application, it
doesn't matter what order they are built in. But the auto-builder
should only publish the application into the repository once all its
runtime dependencies are already in the repository.
> 6) Dependency checking. One advantage of my current GPE build system is that
> every build starts in a clean environment. I know that the build doesn't
> depend on anything not listed as a dependency because it would fail if it
> did. This was one of the first problems I came across when I first started
> trying to build Maemo packages: I used a single scratchbox environment for
> all my development and lots of things had been installed over time: builds
> would be successful even though the list of build dependencies was incomplete
> and the resulting packages would have unexpected dependencies. So, the
> requirement would be to do builds in a clean environment where only the
> specified dependencies are loaded.
>
> There is an argument that says that dependency checking isn't the job of the
> autobuilder: its job is just to build and developers should be checking their
> dependencies themselves. But doing this would improve the quality of the
> packages (although not necessarily user-visible quality).
So, to be concrete, I think this means that the building algorithm has
to be something like this:
build(package)
{
for (each of package's build-dependencies)
{
build(dependency)
dpkg -i dependency-package.deb
}
dpkg-buildpackage(package)
}
main(uploaded_package)
{
start_from_base_tablet_os()
build(uploaded_package)
uninstall_all_installed_packages()
}
> 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. This would
> allow conflicts to be discovered; including conflicts that may never be
> noticed by the development community using extras-devel because no one has
> just the right combination installed. This could be a separate process I
> suppose: a tool which runs every night and just installs everything it finds
> in extras-devel into a clean scratchbox environment.
I like how this contrasts with the build algorithm: each uploaded
package is built in its own clean environment, but test-installed in
an "everything" environment.
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?
Regards,
Neil
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
"Andrew Flegg" <[EMAIL PROTECTED]> writes:
> 1) Simple ability to upload a source package(s).
> 2) Have that source package compiled on as many SDKs as possible (OS 2006, OS
>2007 and OS 2008 should be possible with some/most packages).
> 3) The ability to update a source package in a simple manner (triggering a
>recompile).
> 4) When a new SDK is released, everything should be recompiled and redeployed
>to extras-{devel,testing,...}.
These are the main points for me too, but in addition:
5) Subject to some automated measure of quality (maybe just successful
building), the built packages are automatically published into the
extras{-testing} repository.
6) If it doesn't already exist, an entry in the Application Catalog is
automatically created, including .install file(s) for all supported
OSs.
Then there are (probably obvious) things about the detailed operation
of the above points, like automatically emailing the uploader if a
package doesn't build.
If possible, it might make sense for the interface to the auto-builder
to be integrated into garage.
- It feels reasonable to say that a project must have a garage page,
in order to use the auto-builder.
- Instead of emailing the uploaded in case of build failure, the
auto-builder could submit a bug to the project's tracker instead.
- Garage could provide a convenience page for uploading a source
package to the auto-builder. For the benefit of people with lots of
projects, however, this probably should not be the _only_ uploading
interface; it would be necessary if something scriptable worked
also.
Regards,
Neil
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
[EMAIL PROTECTED] writes: > Sorry, that is not 100% correct. At least I stressed the need for an > autobuilder, too. I think I made that very clear in my mails. And I think > most other people were in favour of it, too. IMHO Nobody would deny the > advantage. "Ferenc Szekely" <[EMAIL PROTECTED]> writes: > we don't ignore it at all. please follow and commen Misha's thread > about the autobuilder. > in case you have a solution then please let us know. we will make sure > that you can set it up for extras. I'm sorry if I was overly categorical there. I have been following the "repositories mess" discussion, but I haven't read every word of every post, so I certainly could have missed things. I feel that with a working auto-build system, many of the process issues that are being discussed in fine detail would simply disappear, or at least become less important; therefore it has seemed odd to me that there is so much discussion of those issues, and relatively little (till now) of auto-building. But, as you say, it looks like this is now being addressed. Over to the new auto-builder thread... Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
"Tim Teulings" <[EMAIL PROTECTED]> writes: > I think that is the main problem. The discussion is long (and so are its > single mails), but the number of participants is rather low (in relation > for example to the number of accounts in garage). I getting a increasing > bad feeling because I post my assumptions and suggestions, somebody else > posts his assumptions an suggestions (and they are all valid and > helpful) but in fact we are all searching in the dark. Community > feedback is low and no technical help visible. The reason for this is that whenever other participants (me, Simon, Andrew, Graham, ...) raise the real issue - i.e. that what we really want is an autobuilder - you, and Quim, and the other high bandwidth participants in this thread, studiously ignore this point! Want more stuff in extras => set up an autobuilder. It's as simple as that. Once most people are using a single repo, package dependency problems will disappear. Within-package quality can be dealt with by the usual free software mechanisms, and others (such as rating and feedback) that have been discussed. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: screen, battery, headphone: sense and modify
"Jesse Guardiani" <[EMAIL PROTECTED]> writes: > Hello, > > As many of you know, Kagu has support for much of this functionality in it's > maemo.py module using a combination of DBUS and filesystem polling. > http://kagumedia.com/projects/kagu/browser/trunk/src/kagu/maemo.py > > However, almost all of this functionality is rather, u, unofficial. And > some of it (like our "Screen Off" functionality) just doesn't work very well. > How can we go about lobbying for official APIs and interfaces to this > functionality? +1, kind of. I'm enjoying Kagu more and more, and it occurred to me today to wonder if it is possible to lock the screen, but not the keys. Then one could do a useful set of things (skipping forward and back, and increasing/decreasing volume) without having to take the tablet out of one's pocket. (I think that's broadly in the category your email is aiming at.) Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Eero Tamminen <[EMAIL PROTECTED]> writes: > This doesn't necessarily need to be provided by Nokia, autobuild could > be also provided by some external party. True. Perhaps, as this thread develops, Nokia will indicate whether or not they might look at doing this. Then, if the indication is "no", I guess the ball is in the community's court. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Quim Gil <[EMAIL PROTECTED]> writes: > This is an invitation to resume all previous discussions about "the > repository mess" and come up with conclusions and actions. Please read > this through and have a say, specially if you are maintaining a > repository with maemo packages out of maemo.org This all sounds very positive to me. The only thing I'd add is that Nokia/Maemo should consider providing a auto-builder service for Maemo packages, such that - developers could upload source code packages - the autobuilder would attempt to build them, for all supported platforms (gregale, bora and chinook) - if everything built successfully, the auto-builder would automatically submit through to the extras-testing repository - if there were problems, the auto-builder would email those back to the developer. Technically this is separate from the repository issue, but (i) I think it is needed, in addition to your repository proposals, in order to dramatically improve the availability and quality of 3rd party packages, and (ii) it would be a major incentive for developers to use extras and extras-testing instead of starting up their own repositories. Please note that, if such an auto-builder existed, this does not mean that developers should stop building the code themselves - because it would be wrong to upload to the auto-builder before having some confidence that the package will build. It would be reasonable, however, for a developer to have only the current SDK (e.g. chinook) installed, to do their development using that, and to check that their package builds in that SDK's rootstrap, and then to use the auto-builder to handle building (and publishing packages) under the other platform SDKs. In some cases, of course, it will be impossible to make an application work on the older platforms. Such cases could be handled by allowing a "Platforms: chinook" or "Platforms: chinook, bora" declaration in the source package upload. As regards implementation, note that the mud-builder project in garage has already done some useful work here - but in any case I don't think this auto-builder would be technically difficult; it's more a matter of whether you agree that this service would be a good idea and could invest the management resource to make it available. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Developing for all IT platforms
Santtu Lakkala <[EMAIL PROTECTED]> writes: > I have targets for mistral/2.0 (to support mistral, scirocco and > gregale), bora/3.0 (to support bora 3.0, 3.1, 3.2) and now chinook-beta > to support the upcoming N810. I then compile packages first on mistral > and see if they work on bora -- if they don't, rebuild with bora... Thanks; together with your recent blog post that contains the details of how to set this up, that is exactly what I was looking for. > I didn't find documentation for chinook .install files, but reading the > source, I got the following: > > 8<8<8< > [install] > package = > catalogues = > > [] > name = > uri = > dist = > components = > 8<8<8< > > Of course the .install file can still include the repo_name, repo_deb > and repo_deb_3. For example, mh-shot-tool install file currently looks > like this: > > 8<8<8< > [install] > repo_name = maemo-hackers > catalogues = maemo-hackers-chinook > repo_deb = deb http://maemo-hackers.org/apt mistral main > repo_deb_3 = deb http://maemo-hackers.org/apt bora main > package = mh-shot-tool > > [maemo-hackers-chinook] > name=Maemo Hackers for chinook > uri=http://maemo-hackers.org/apt > dist=chinook > components=main > 8<8<8< Fantastic, thanks. Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Developing for all IT platforms
Something that's been bugging for a while, and will become more important now that N810 is here... Is there a recommended procedure for setting up Scratchbox so that one can easily compile an application and build its package for all of the IT platforms (i.e. ideally: 770 with latest 2006 OS, 770 with HE, N800 with latest 2007 OS, and N810 with whatever its OS is). Then, similarly, is there a recommended procedure for publishing the packages, and/or setting up a repository, and/or providing .install files, so that an IT user will easily be able to get the version of the package that is right for them? Many thanks, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
DSME code?
I happened to come across this commit mailing list: https://garage.maemo.org/pipermail/dsm-commits/ Is this related to the 770/N800 closed source DSME code at all? It looks like it might be. (I have no strong interest in this myself, but I know that from time to time questions are asked about what DSME is, so I thought this might be useful to point out...) Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
af-defines.sh call removed from /etc/profile
I just installed Scratchbox and the 3.1 SDK, then upgraded to the 3.2 SDK. I noticed that the upgrade from 3.1 to 3.2 makes this change to /etc/profile: [sbox-SDK_ARMEL: ~] > diff /etc/profile.dpkg-old /etc/profile 9d8 < source /etc/osso-af-init/af-defines.sh Is that correct, or should I add the deleted line back? Thanks, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Software categories
Marius Vollmer <[EMAIL PROTECTED]> writes: > It is better to have the control point at the repository than in the > devices. If we change our minds (and introduce a new category, e.g.), > we don't need to update all the devices, we can just implement the > change in the repository. OK, good point. For installed applications, it seems to me that either way the user will have to do an update, either of the installed applications, or of Application Manager itself (post-Chinook). But for non-installed applications, which are the majority, fixing the repository is a clear winner. Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Software categories
Marius Vollmer <[EMAIL PROTECTED]> writes: > Rather, I would hope that we get the repository mess under control by > having a few well maintained official repositories and then clean up > the category mess by tightly controlling the categories of the > packages in the official repositories. What does "well maintained" mean? If it means rejecting an upload that doesn't fit one of the official categories, then I see no significant difference between that and what I said. Otherwise, how do you envisage good maintenance solving this problem? > The category mess is only a minor detail when looking at the general > repository mess. Actually, I personally don't perceive a "general repository mess". as far as automating the process of adding a new repository is concerned, I'd say the .install files have worked very well. On the other hand, the profusion of category buttons in Application Manager is a very perceptible problem. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Software categories
"Paul Klapperich" <[EMAIL PROTECTED]> writes: > Perhaps the application manager could require one of those categories is used > or it shows up "Not Installable" just as occurs when the package is not in the > user category? Or the package installs, but then shows up under an "Unclassified" category. That would be less painful, but I think would still create an appropriate pressure on developers to choose one of the official categories (and to formally request a new official category, if there really isn't an appropriate one). Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: do we need garage sandbox repos?
Neil MacLeod <[EMAIL PROTECTED]> writes: > I've produced the following subset of broad categories for consideration: > > Communications > Games > Graphics > Multimedia > Office (or perhaps Business Tools?) > Programming > Support > Themes > Utilities (or perhaps Tools?) I very much support doing this, and think this subset is a fine first cut. Just one thought: isn't the problem here similar to that of desktop menu organization? Perhaps you could look at Debian/Fedora/... menus and take some guidance, or just check your own proposal, from there. Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo emails classified as spam
Santtu Lakkala <[EMAIL PROTECTED]> writes: > Frank W. Kooistra wrote: >> The gmail account has a spam directory >> tag the erroneously spemmed messeges as " This is not spam" >> and they will be taken off spam lists >> if every body does that they will be cleared > > I have done this actively -- a couple of times a day since I noticed > that the mails were being "spammed". It doesn't help the fact that > there's a mail server with no reverse, which is considered as a mark of > spam by some mail servers. If google has such check, it's getting less > effective on every "not spam" operation. Or you could say that the check is getting ever closer to the level of effectiveness that is actually correct, given the average configuration of mail servers in the Internet. I personally am not persuaded that this should be regarded as a maemo bug, and don't think that raising a bug for this in bugzilla is helpful. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Intel's Internet Mobile Device
Carlos Guerreiro <[EMAIL PROTECTED]> writes: > This is a positive development for Nokia and other companies > building or planning to build devices on GNOME software. > Intel's use of Hildon is welcome and seen as positive development. > There should be plenty of opportunity for collaboration. That's really good news. I'm glad that Nokia are seeing things this way. Thank you for commenting. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Timer function
Fred Lefévère-Laoide <[EMAIL PROTECTED]> writes: > Hi, > > I plan to write a software metronome and I wonder what would be the > best way to get a timer precise enough for that purpose ? I wrote one using just g_timeout_add(), and that seems to me to work well enough. I've put the source code up at http://www.ossau.uklinux.net/guile/metronome.scm, in case you'd like to look and don't mind reading Scheme. > The other problem is what's the best way to make a short sound > (eventually corresponding to a note ...) Indeed. I don't have a solution for this yet; would be interested to hear if you find a nice one. Currently my metronome is just visual. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Intel's Internet Mobile Device
"Pablo Chacin" <[EMAIL PROTECTED]> writes: > Hi > > I just came across this news at Endgatget. > http://feeds.engadget.com/~r/weblogsinc/engadget/~3/109417695/ > > Here a technical the presentation: > https://intel.wingateweb.com/published/UMGS003/UMGS003_100eng.pdf > > Looks interesting. Same approach than Nokia. They actually even plan to use > Hildon. And they claim to have 20+ applications ready to go, many (according to the gallery) apparently Hildonized. If those applications are free software, it may be trivial to port them over to the 770 / N800 ... I may be being over-dramatic, but this feels to me like crunch time for Nokia. They will either decide now to accept the potential of their platform and go fully free -- or they will batten down the hatches in any way they can, in an attempt to prevent other players from leveraging their work. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: No more 770 bug activity?
Acadia Secure Networks <[EMAIL PROTECTED]> writes: > Marius, > > re: your comment > > > Nokia currently stands in the middle between open and closed. I > imagine > it is frustrating to both sides. > > > > Is the reason that Nokia has some portions of the software as closed source, > because the suppliers of those components,or the underlying hardware > components, are requiring Nokia to keep such software closed soruce? > > Or, on the other hand, is Nokia trying to protect its own software IP by > having > some of the software closed source? > > I would be surprised if it were the latter because [...] Just as a matter of fact: a Nokia employee has recently stated on this list that the osso-ic component is closed source for no other reason than that closed source is the default at Nokia (even when developing for the Maemo platform, apparently). It was explicitly asked whether any IP was involved, and the answer was no. (Unless I misunderstood, of course...) Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: No more 770 bug activity?
<[EMAIL PROTECTED]> writes: > I'm not going to get into details about the packages mentioned, but as a > general answer... Which I appreciate ... I also appreciate that there have now been lots of other followups on this, and that my own reply is late, so I won't repeat what others have said, just a couple of additional / different angles ... >>So why on earth was it ever closed-source? > > As mentioned in my previous email, project management issues had a big > weight on this kind of decisions. Objectively, when you are a huge > company and you need to deliver quickly software matching commercial > quality standards it is probably faster, cheaper and easier to deliver > it as closed source. I don't understand this, though. Nokia could have done _exactly_ the same thing as they did do, in terms of development, project management, quality standards and release. The only difference I'm suggesting is that every time they release a new firmware, they also put up a tarball of the code, with some open source license. Nokia are not obliged to take anyone else's changes back into their official product. On the other hand, this would allow the community to develop the component if they need to (as in the future 770 situation). Other responders have conflated the concept of free software with things like CVS/SVN access for developers outside Nokia. But in fact such things are extraneous and entirely optional. Free software only requires that the source code ends up being released under a free software license. > The UI is different, it was decided to have it closed in order to > protect it from changes and deviations out of the control of the > project. Unless _I'm_ misunderstanding you, this suggests a fundamental misunderstanding on Nokia's part (and hence is important to drill down on, to provide input into those turning wheels). As I have already said, releasing code as free software does not require Nokia to accept any changes that others might make to that code. What is the process that Nokia believes could result in "changes and deviations out of the control of the project"? > And now, back to the wheels. I hope that these email discussions contribute to those wheels. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Maemo Language bindings and priorities
<[EMAIL PROTECTED]> writes: > Hi, > > I'm collecting developer feedback regarding language binding needs on maemo. > Hildon and other APIs need bindings in order to have native support in > languages other than C. Currently there exists unofficial bindings for C++, > for example, and bindings for Python. So the question is what bindings do you > need for your development, for what language, and why (if not obvious)? > Thanks! I've done some work already on Guile Scheme bindings, and will continue that - although very slowly, as time permits. I use these bindings for various small applications aimed at my own needs - nothing published yet. I appreciate that Scheme is a niche market (and Guile Scheme even more so), so I don't expect any official support from Nokia on this. But given your email I thought you might like to be aware of this work. Regards, Neil ___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
Re: No more 770 bug activity?
Kimmo Hämäläinen <[EMAIL PROTECTED]> writes: > On Tue, 2007-04-03 at 17:54 -0400, ext Andrew J. Barr wrote: > ... >> Also stuff like ke-recv, I suspect is an attempt, probably by TI or some >> other third party, to obfuscate some so-called "intellectual property" >> that would normally go into a kernel driver. Something along the lines >> of the ipw3945d that existed for a while. > > :D No, it's quite simple piece of code. It could be open-source in the > future (I have suggested it and it seems wheels are turning). It handles > automounting of memory cards, updates bunch of GConf keys, and sends > some D-Bus signals (background killing and low-memory), according to > certain HW events. Btw. I wrote it, so TI is not involved (unless they > have planted ideas to my brain while I was asleep). > > BR, Kimmo So this is a very interesting example, then. This is a component that apparently doesn't incorporate any pre-existing code with a tricky license, is not complex enough to have "intellectual property" that Nokia might want to protect, and was written by a free-software-friendly person (yourself!). So why on earth was it ever closed-source? I wonder similarly about things such as the Media Player UI and the metalayer-crawler. There's no rocket science there, so why are these components closed? Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Enriching the Application Manager scripting experience
Marius Vollmer <[EMAIL PROTECTED]> writes: >>> I managed to sneak a bit of Lisp into the Application Manager, but I >>> kept it enterprise ready by hiding it behind XML. So while the new >>> way of writing .install files looks quite verbose, it is really quite >>> simple. Simple maybe, but definitely ugly. > I myself prefer the S-expression approach: > >(install-instructions > (update-catalogues >(catalogue > (tag "com.foobar.repository.automatic") > (version 0) > (name (en_GB "Foobar Catalogue") >(de_DE "Foobar Katalog")) > (uri "http://example.com/";) > (dist automatic) > (components "main"))) > (install-packages >(pkg "maemo-foo"))) > > which can be shortened to > >(install-instructions > (update-catalogues >((tag "com.foobar.repository.automatic" 0) > (name (en_GB "Foobar Catalogue") > (de_DE "Foobar Katalog")) > (deb "http://example.com/"; automatic "main"))) > (install-packages "maemo-foo")) > > Maybe I go with this approach if XML turns out to be too unwieldy. +1 Much nicer. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: becomeroot once again but with password
Marius Gedminas <[EMAIL PROTECTED]> writes: > On Wed, Feb 21, 2007 at 04:27:39PM +0100, Marc Zonzon wrote: > >> because I don't want to open root to anybody, to put a password for user was >> not alsways convenient even with 770 as pointed in the BecomeRoot2 howto, >> and >> it seems that on N800 the system want to forbid it because it answers: >> >> ~ $ passwd >> The password for user cannot be changed. > > That's because you are running passwd as user, and user doesn't have a > password set. If you run 'passwd user' as root, it should work. Yes, that works (at least it did on the 770). I've used this to set a password for user so that I can then run an FTP server for user. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800: Loss of touch screen sensitivity/pressure detection
Neil MacLeod <[EMAIL PROTECTED]> writes: > A number of users, including myself, have reported a loss of touch > screen sensitivity which can be visualised by using the Maemopad+ > application. In my case, I've lost touch screen sensitivity in the > right hand part of the screen covered by the vertical scroll bar > meaning that page scrolling by dragging the thumbtrack is a hit and > miss affair - I may have to click the stylus on the screen up to 3 or > 4 times before a hit is registered. I'm seeing something like this too. For me it occurs most frequently when I type my VNC Viewer password, which contains two 3s. The first 3 is usually OK, but the second one hardly ever registers until I've tried 3 or 4 times. Another case is navigating menus where the "mouse" needs to be "held down" the whole time (Emacs via VNC Viewer). Almost always, I don't get as far as the menu item that I want, because the N800 thinks I've lifted the stylus up - when in fact it's still touching the screen. Would be great if this was a software problem, but my current impression is that something about the N800 screen is a lot less good than the 770. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: How VNCVIEWER can bring non maemo applications onto the N800
Detlef Schmicker <[EMAIL PROTECTED]> writes: > Hello, > > the last weeks I played around a little with setups, which allow to run > applications on N800, which are not ported to maemo. The main problem > using this kind of applications is the missing keyboard, if they are > cross compiled. In penguinbait's experiments, I believe he uses xkbd to solve this. Presumably that would work with your approach too? > vncviewer (http://vncviewer.garage.maemo.org/ ) can handle this, as > easily is tested connecting to a debian linux machine and trying all the > applications availible. Oh I see, that is clever! (I guess xkbd is still possible, but the vncviewer keyboard is much more convenient.) > Have a look at the screen shot at http://physik.de/770/ with debian / > testing runnin on a N800 within chroot and vncviewer. Very nice! To check that I've understood correctly: - Are you saying that everything from the debian/testing arm port will run without needing recompilation? - Am I right in thinking that the chroot is only needed so as not to mix up the debian/testing distribution with the maemo? (In other words, it's not required by something about how Xvnc and vncviewer work?) > I tried three different setups (all are working, but none is enduser > ready:-) > > 1.) I compiled Xvnc using the source from debian/testing within bora. > This was running on N800. Than I started Xvnc for display :8 (from > xterm) set the display variable and started the crosscompiled but > unported version of e.g. rdesktop. Than vncviewer was started to view > this localaly. How does a bora-compiled Xvnc differ from Xvnc in debian/testing? Is it just which libraries (libc etc.) it links to? > > This way one can use cross compiled version of linux software. > > 2.) I installed the debian armel port within a chroot environment, > installed the vncserver package within this port and did basicaly the > same as in 1.) > what to be done for setup this: > I have debian / armel port running on N800 on a 512 internal flash. > > I had to format it with ext3 filesystem (I think ext2 would have been > OK) > I had to insmod mbcache and ext2 module > I mounted it > I unpacked the rootfs from > http://lists.debian.org/debian-arm/2007/01/msg00034.html > > I installed chroot and chrooted to the directory > > (I installed a new version of tar (compiled from sources), as the > busybox does not support bz2 files) > > Now I do a gpt-get update within chroot ... > > This way all packages within this debian armel port seem to be usable on > the N800 Cool. So, comparing (1) and (2), one basically has a choice between cross-compiling and chrooting - right? > 3.) > I did basically the same but with debian / testing for the arm platform. > > I compiled debootstrap for maemo, used it to install debian / sarge into > a chroot environment. Than I configured /etc/apt/sources.list to use > debian testing within the chroot. Did a apt-get update and apt-get > dist-upgrade (if I remember correctly I had to remove apt-get first and > install the version from debian / stable download dpkg -i), installed > vncserver and icewm (window manager) and two init scripts: > /root/init.sh with on N800 to start the chroot environment > #!/bin/sh > insmod /mnt/initfs/lib/modules/2.6.18-omap1/mbcache.ko > insmod /mnt/initfs/lib/modules/2.6.18-omap1/ext2.ko > mount /dev/mmcblk0p1 /media/mmc2 > chroot /media/mmc2/sid-arm /root/init.sh As you say, this seems effectively identical to (2). > and within the chroot environment there was So this is /root/init.sh, is it? > #!/bin/sh > Xvnc -depth 16 -geometry 800x600 :8& > export DISPLAY=:8 > icewm& > mount proc /proc -t proc > mount devpts /dev/pts -t devpts > xsetroot -solid "rgb:00/00/30" > /bin/bash > > > And up was the debian testing on the N800. Well I've already said it, but I'll say it again: very nice! And in my view this is a nicer solution than penguinbait's, because it means you can have maemo and non-maemo sessions (actually, any number of them!) up simultaneously, and switch at will between them. (Does VNC Viewer already allow multiple instances of itself?) > Thus anybody discussing, helping ... to get (I would love the debian / > testing) setup enduser ready? A 300 MByte root fs I do not want to > deliver, which would be the easiest way :-) Is 300Mb the size of the minimal debian/testing system (that includes chroot and Xvnc)? I would hope that a minimal system could be smaller than that. Once people have the minimal system installed, they can apt-get install anything else they want, so it will be OK to trim the starting package really down to the absolute minimum. > Or getting the first setup developer ready, so that they may easily > crosscompile an launch application they love. How to pack this for maemo > (dependence an vncviewer and Xvnc server (not x11vnc as in 2006 > application list :-) In my view this option is not so interesting, because apt-get install is a lot more fun than cross
[maemo-developers] Correct place to enter N800 discount code?
Hello there. When I tried to order my N800 just now, the only place that I could see for entering the discount code was on the screen that you get to using the "Use Promotional Code" button on the order summary page. But when I entered my code in the box, I got a "code not valid" message. So... - Is that the right place to enter the code, or is there somewhere else? - Does the code validation depend on email address? Following the recommendation to use a "work email address", I used my day job email, which is different from the email that Nokia sent the code to. - Does the validation perhaps depend on when in the process you click the "use Promotional code" button? I did it after selecting an Express Evening delivery - should I have done it before changing from the default delivery option, perhaps? - Has anyone else had a problem like this? And got past it? All thoughts gratefully received. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Emacs work: porting to Maemo
Marius Gedminas <[EMAIL PROTECTED]> writes: > On Wed, Jan 24, 2007 at 07:22:03PM +, Ross Burton wrote: >> On Wed, 2007-01-24 at 14:08 -0500, Ted Zlatanov wrote: >> > I'm currently working on porting Emacs to Maemo, >> >> It's a small point, but isn't emacs an odd choice for porting to maemo, >> with emacs being a text editor designed for keyboard use, and all maemo >> platforms having no keyboard. If you have a bluetooth keyboard paired, >> emacs will just work, otherwise using it would be a whole new world of >> pain surely? > > Maybe, and maybe not. For an experienced vim user, vim with the 770's > virtual keyboard is more convenient than Notes. I speak from > experience. I've been able to get some work done in Emacs via VNC. It turns out that there are either menu items or ESC- bindings for most of the operations that I commonly need. Menu items are easy with the mouse, and for ESC the hardware key works. Interestingly - given Ted's involvement - the thing that's most clearly suboptimal for me at the moment is Gnus. (Perhaps because I use it so much!) In particular, it would be nice to be able to select a message from the summary buffer using the mouse. Perhaps I just need a custom binding to do that. I have found this useful - (define-key gnus-summary-mode-map "'" 'gnus-summary-mark-as-spam) - because ' is quicker than "ESC d" and I seem to get a lot of spam. I believe that using Emacs directly on the 770 would be broadly similar to what I currently do through VNC, but obviously would also give us more options, such as using Gnus for local mail on the 770; so I look forward to the results of Ted's work very much. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Tracking downloads from garage repositories?
"Levi Bard" <[EMAIL PROTECTED]> writes: >> Is there any way to get statistics for downloads from garage repositories? >> It would be nice if said statistics were available from a project's garage >> Web page. Currently, it only seems possible to get download statistics >> for files downloaded from the garage Web pages for a project. > > I'd like to second this request. Since my apps were added to the > extras repo, my garage downloads have dropped significantly. +1 Although I note that currently there isn't any formal link between an extras upload and the associated garage project, is there? I guess to make such a link, we'd need to specify that people add a header to the control file of the packages that they create (or one of the other uploaded files), to specify the garage project name. If we did this, it would also be possible to make all the uploaded files appear automatically on the project's download page, which would be very nice. Sounds a bit non-trivial, though, and I'm sure sorting out the support for multiple revs of Maemo is more important right now. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Happy birthday Maemo!
Ferenc Szekely <[EMAIL PROTECTED]> writes: > Time goes fast and Maemo is already one year old. On this special > occasion, I am proud to announce our brand new project hosting > environment: https://garage.maemo.org . We would like to invite every > Maemo and Internet Tablet related software projects to join. It looks nice. I especially noticed the "Code Snippets" section, which I haven't noticed before on other hosting sites. Is this a new idea? I expect it will be excellent for collecting useful bits of scripting language code. Does the package building option here produce a package that can be directly installed on the device? And if so, are those packages for the 2005 OS or for 2006? > Thank you for all the support you have given to us during this year! It's been a fun time. Thank you to you and your team too. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] xskat and maemo fonts
"Hans J. Koch" <[EMAIL PROTECTED]> writes: > The program can be started (from xterm), but immediately exits > displaying a message "Font 9x15 not found". > > xskat has a commandline option "-font font_name" which seems to expect > a pixel size like 9x15 or 10x20. On my laptop, several different sizes > work. How can I find out which values are possible on the 770? You could run xlsfonts, if it's already there. Alternatively you could compile and run the xlsfonts code in scratchbox, or write your own little program to call XListFonts and display the results. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] GStreamer plugin development
Corentin Baron <[EMAIL PROTECTED]> writes: > Hello there, > > I've made a gstreamer plugin [...] but I can't manage to build the > plugin development package to build on the ARM target. > > Does anyone know how I could handle this? How are you trying to do the ARM build, and where is the build failing? Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Zapped wtmp...
"Michael Saunby" <[EMAIL PROTECTED]> writes: > Now you've made me aware of this I've deleted /var/log/wtmp. I doubt > it was using as much storage as you suggest but if I'd really been > thinking I'd have done a df before and after - maybe someone else will. For me, du -sk said that wtmp occupied 178Mb (presumably uncompressed), and deleting wtmp reduced the figure reported by df -k by 18Mb (presumably compressed). Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Input Method Documentation
Phil Cowans <[EMAIL PROTECTED]> writes: >> Does this also mean that we may be getting a port of Dasher for the >> 770 soon? I really hope so! >> > This is indeed the plan. (1) is coming along pretty well. I haven't > stared on (2) yet, but there's quite a lot of scope for various > optimisations so I'm hoping it's not too much of a problem. I'll let you > all know when I have something which is usable. Fantastic news; I look forward to it. Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Building deb packages for the Nokia 770 is very easy
"Ian" <[EMAIL PROTECTED]> writes: > disse --> Neil Jerram > Thx for these explanations,you are helping me out a lot. > I am not sure about the difference between Build-Depends and Depends : > > originais -> Build-Depends: debhelper (>= 4.0.0) > > originais -> Depends: maemo I'm not 100% sure either, but I believe "Build-Depends" is only relevant when someone wants to rebuild your package from its source: it tells that person what they need to have installed in order to do the build. "Depends" on the other hand lists the requirements for the binary package installation to work. > I know Nokia recommends only depending on maemo but can I depend on > something else if it is already packaged for the 770 ? Here I would agree with the answers that Kalle and Michael have already given. > I mean how would this work on the actual device. I am not with my > 770 at the moment so I cannot look at its /etc/apt/sources.list but > will i find some maemo repositories when i do?. The application > installer is what then... some Hildonised front end to apt? I believe it's currently much simpler than that. Currently there are no repositories for application installer (=> 3rd party) packages, just individual .debs on people's websites. (The repository that the maemo.org pages speak about is the one used to manage the 770's base filesystem + program set, not application installer packages.) Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Input Method Documentation
"Phil Cowans" <[EMAIL PROTECTED]> writes: > Hi all, > > I just thought you might be interested in some notes I made on the IM > framework having spent an afternoon figuring out how it works: > > http://www.inference.phy.cam.ac.uk/pjc51/hildon_im.txt > > Hope it's useful, Well I'm not working in this area myself, but judging by recent conversations on this list I expect this will be very useful for the people who were having those conversations. Does this also mean that we may be getting a port of Dasher for the 770 soon? I really hope so! My understanding is that when your team last tried to port Dasher, there were two issues. (1) was that the Hildon IM framework wasn't open; but I presume that is solved (or in the process of being solved) by the analysis that you have posted. (2) was that Dasher's CPU requirement was too much for the 770 - do you have a solution for this now as well? Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Building deb packages for the Nokia 770 is very easy
Xavier Calbet <[EMAIL PROTECTED]> writes: > I have had problems with the regular > building of packages with dpkg-buildpackage, etc. > When I reach the "..as described in the > new maintainer guide.." I get lost. Does any > novice > really find this guide useful? Well, I had never built a Debian package before, when I built my first package for the 770. If you want to say where you get lost, I'd be happy to try to explain. > I also get lost in the "but removing lots of stuff > that the 770 doesn't need or can't > handle" because I do not know what the 770 > cannot handle, unless I do trial and error > (and of course that takes forever). OK. The only files I think you need are the following. changelog - This should follow the format specified by the NM guide, but you are free to put as much or as little actual information as you like. The debian-changelog mode for Emacs makes it trivial to get the format right. compat - I've actually no idea about this; I just left it as generated by dh_make. control - Easiest by example: Source: guile-gnome-dev Section: devel Priority: optional Maintainer: Neil Jerram <[EMAIL PROTECTED]> Build-Depends: debhelper (>= 4.0.0) Standards-Version: 3.6.0 Package: guile-gnome-dev Architecture: any Depends: maemo Description: Guile language bindings for the GNOME platform Guile language bindings for the GNOME platform copyright - Per NM guide. (Tedious, but important for free software.) docs - Any files that you want to be installed in $prefix/share/doc/, like this: AUTHORS NEWS README info - Not sure, but probably not needed. rules - As generated by dh_make, plus the two changes described in my previous email. > By the way I am trying to build the deb packages > for perl/PDL which should make the Nokia770 > a powerful calculator with graphics. I already > have the code running on the Nokia 770. Sounds fun; good luck with the packaging. Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Core-iSCSI/Nokia 770
"Nicholas A. Bellinger" <[EMAIL PROTECTED]> writes: > I am very interested in hearing from voluenteers from the Maemo > community who would be interested in developing a UI that makes script > calls in order to control the core-iscsi (and eventually open-iscsi) > stacks. When you say "script calls", do you mean shell command line calls - and hence things that can be done from within a scripting language using system(2) ? If so, I'd be interested in doing this as a test case for my Guile packages, which wrap the Gtk and Hildon widget set on the 770. You may have been thinking of doing the interface in C, and not want to introduce further dependencies, and I can understand if that is the case. It could still be interesting to use my bindings to prototype and demonstrate the interface, and then convert it to C later. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Building deb packages for the Nokia 770 is very easy
"Stephen DeGabrielle" <[EMAIL PROTECTED]> writes: > I'd really like to just use 'dpkg-buildpackage -rfakeroot -b' but it > spits errors at me; > > My problem seems to be that I use ./configure;make;make install to compile. Me too, and I haven't had a problem with this. > the Maemo Tutorial seems to want me to > 'Run autogen.sh to generate application build configures: ' I think that's assuming that you're starting from the developers' CVS repository for a product. I recommend starting from the most recently released tarball for the product in question, and then following the Debian new maintainer guide. At least that worked for me. In outline, in other words: - Get and unpack a pristine released tarball. - Go into the root dir of the unpacked tarball. - Do the dh_make step as described in the new maintainer guide. - Edit the debian/* files generally as described by the new maintainer guide, but removing lots of stuff that the 770 doesn't need or can't handle: pre and post scripts, manpage, etc.; also change debian/control so that the only dependency is maemo. - In debian/rules, make two key changes. - Change the configure line so that it has "--prefix=/var/lib/install/usr". This means that the package will find its files in the right place once it has been installed. - Add two lines like this after the $(MAKE) install line: mv $(CURDIR)/debian/PACKAGE/var/lib/install/* $(CURDIR)/debian/PACKAGE/ rm -rf $(CURDIR)/debian/PACKAGE/var (replacing PACKAGE by your package name). This means that the files in the .deb appear to be rooted at /usr, which is what the 770's application installer needs. - dpkg-buildpackage -rfakeroot Good luck! Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Scheme for 770 available
"Stephen DeGabrielle" <[EMAIL PROTECTED]> writes: > I have just made mzscheme for the In roughly the same area, I've been working on Guile packages for the 770. So far I have guile, slib, g-wrap and guile-gnome packaged. They basically work, but there are issues to iron out with how some of the Gtk and Hildon widgets are wrapped, so I wouldn't say it's fully ready yet. (If anyone is interested to help me with this, please let me know.) Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Scheme for 770 available
"Stephen DeGabrielle" <[EMAIL PROTECTED]> writes: > I have just made mzscheme for the Cool. (Speaking as a fellow Schemer.) > You will need xterminal to run it. It doesn't matter where you put it as I > have not worked out how to package it yet, so all the libraries are > missing. I built it on ubuntu on Q(emu) on osx. If you need help after checking Armin's references, I'd be happy to help you with this. Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: libfakeroot errors
Riku Voipio <[EMAIL PROTECTED]> writes: > On Sunday 26 March 2006 16:15, Neil Jerram wrote: >> >> libfakeroot: connect: Cannot assign requested address > >> For the record, I've now managed to avoid these errors by moving my >> maemo work to a higher spec machine. (Specifically, from a Pentium >> III 800MHz with 128Mb RAM, to a Pentium III 935MHz with 256Mb RAM.) > >> Of course, it could be that some other factor in the move was >> relevant, such as the way I installed or used scratchbox (with the >> benefit of more experience), but my guess is that performance was the >> main factor. > > You are running out out tcp/ip local port range. Linux kernel will assign a > static amount of local ports on your system startup, with a quite low default > for systems with little ram (1024 ports minimum afaik). > use /proc/sys/net/ipv4/ip_local_port_range to set the range. Non-ancienct > versions of scratchbox have already measures against this issue. Aha! Thanks for explaining this. If I need to switch back to the other machine, I'll try that out. Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: libfakeroot errors
Neil Jerram <[EMAIL PROTECTED]> writes: > Neil Jerram <[EMAIL PROTECTED]> writes: > >> Does anyone know what the following errors mean? I get them when >> trying to build an ARM package in scratchbox; the corresponding i386 >> package builds with no problem. > > [...] > >> libfakeroot: connect: Cannot assign requested address > > I'm still suffering from these libfakeroot errors in scratchbox > builds, now for both ARM and PC targets. [...] For the record, I've now managed to avoid these errors by moving my maemo work to a higher spec machine. (Specifically, from a Pentium III 800MHz with 128Mb RAM, to a Pentium III 935MHz with 256Mb RAM.) Of course, it could be that some other factor in the move was relevant, such as the way I installed or used scratchbox (with the benefit of more experience), but my guess is that performance was the main factor. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: libfakeroot errors
Neil Jerram <[EMAIL PROTECTED]> writes: > Does anyone know what the following errors mean? I get them when > trying to build an ARM package in scratchbox; the corresponding i386 > package builds with no problem. [...] > libfakeroot: connect: Cannot assign requested address I'm still suffering from these libfakeroot errors in scratchbox builds, now for both ARM and PC targets. I've read everything I can find on the web about fakeroot, and believe that this error is generated when an instance of libfakeroot-tcp tries to connect to the faked daemon. A complex build will launch (directly or indirectly) hundreds of subprocesses, and each of these will preload libfakeroot-tcp and make a connection to faked; and they should all be specifying the same IP address (127.0.0.1) and port number (reported by faked when it starts up). Therefore my best current guess is that this is a performance issue which shows up somewhat randomly, perhaps dependent on how many other subprocesses have connected to faked in the last few seconds, and how quickly their sockets are being cleaned up. Can anyone else support or throw further light on this? Does anyone know if the problem is likely to be cured by moving to a faster machine? (I'm seeing this on a Pentium III 800MHz with 128Mb RAM.) Many thanks, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Tips for making an application installer package
"Kasper Souren" <[EMAIL PROTECTED]> writes: > Does anyone have a similar method for Python? > I*d like to create a package for MaemoDict. > And, would it be okay to include dictd in the package, or is it better to > point people to the official Debian arm package? (With apologies for the late reply...) IMO relying on official Debian arm packages is a poor substitute for a proper 770 application installer package. I'd like to minimize the actions I take that require root. (On the other hand, if an official arm package had (i) no postinst or prerm scripts, and (ii) no internal hardcoding of its install location, and (iii) no dependencies except "maemo", it should Just Work as a 770 package. Someone who knows dpkg-deb could probably write a script to check (i) and (ii), and fix up (iii), such that a 770 package could sometimes be created automatically from an official arm package.) Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] libfakeroot errors
Does anyone know what the following errors mean? I get them when trying to build an ARM package in scratchbox; the corresponding i386 package builds with no problem. ... dh_installman dh_strip libfakeroot: connect: Cannot assign requested address Use of uninitialized value in pattern match (m//) at /scratchbox/devkits/debian/bin/dh_strip line 136. libfakeroot: connect: Cannot assign requested address Use of uninitialized value in pattern match (m//) at /scratchbox/devkits/debian/bin/dh_strip line 125. libfakeroot ... (repeat last 4 lines lots of times) ... Thanks, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Adding swapon/off to Jakub's Load-Plugin applet
"Armin M. Warda" <[EMAIL PROTECTED]> writes: > Andrew Flegg recommends to >> Open a pty and drive a root-enabled shell through `sudo gainroot'? > > Unfortunately, I do not know how to do that. I am not an experienced > hacker or C coder, but I try to contribute. Can anybody provide some > C code sniplet that demonstrates how I can open a pty and drive a > root-enabled shell through sudo gainroot? > >> Then users will only have to ensure R&D mode is enabled without any >> further hacking. > > Yes, that would be much better than hacking /etc/sudoers. > Everybody who wants to use swap has to enable R&D mode anyway... In my experience, continued use of R&D mode is a lot less stable than changing /etc/sudoers and then switching back to normal mode. My experience may have been random, but until that's proved I wouldn't want to keep running in R&D mode all the time. Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Tips for making an application installer package
Through somewhat painful trial and error, I've discovered that the most effective way to make a package from a standard source tarball (which uses autoconf) is to: - configure with --prefix=/var/lib/install/usr - add the following lines to debian/rules after the $(MAKE) install line: mv $(CURDIR)/debian/p/var/lib/install/* $(CURDIR)/debian/p/ rm -rf $(CURDIR)/debian/p/var (where "p" is replaced by the package name). This method means that the installed files correctly reference /var/lib/install where they need to (e.g. config files, shell scripts, libtool .la files), but that the .deb contains files whose names don't include the leading /var/lib/install - which appears to be what the application installer requires. Has anyone else reached the same or a different conclusion? Are these tips already documented anywhere? Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Best IDE for maemo development?
Eloi Crespillo Itchart <[EMAIL PROTECTED]> writes: > Hi, > > A little survey about your development preferences: > > For the people that develops often on maemo, what IDE/set of tools have you > found to be essential to this task? > > Anjuta? Emacs? Kdevelop? Eclipse? devhelp? ... Emacs for me. I haven't done very much yet, but Maemo development doesn't seem so different from development in general. I'd consider an IDE if it used Emacs as its text editor; otherwise I'd just lose too much functionality by moving to an IDE. (And why oh why does every IDE need to reinvent the editing wheel anyway?) Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Problems with scratchbox installation
Vladislav Grinchenko <[EMAIL PROTECTED]> writes: > Have you tried running run_me_first.sh as root? > Make sure you *login* as root (su -) rather then change to root. > groupadd is in /usr/sbin/ which might not be in your path. Also note that if you installed using the .debs, you don't need to do run_me_first at all; the install did it for you. Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Recovering from bad package install
Simon Budig <[EMAIL PROTECTED]> writes: > Neil Jerram ([EMAIL PROTECTED]) wrote: >> If I accidentally try to install a package with a preinst or postrm >> script, it fails as documented at >> http://www.maemo.org/platform/docs/howtos/howto_making_an_application_package.html, >> with an error message about not being able to chroot to >> /var/lib/install. >> >> My question is: having done this, how can I recover back to a sane >> state, where I can fix the package and then try installing it again? >> Nothing that I can think of works, as shown by the transcript appended >> below. > > For me it helped to remove the preinst and postrm scripts manuall. Many thanks, that's done the trick. Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Recovering from bad package install
If I accidentally try to install a package with a preinst or postrm script, it fails as documented at http://www.maemo.org/platform/docs/howtos/howto_making_an_application_package.html, with an error message about not being able to chroot to /var/lib/install. My question is: having done this, how can I recover back to a sane state, where I can fix the package and then try installing it again? Nothing that I can think of works, as shown by the transcript appended below. Many thanks, Neil [sbox-SDK_PC: ~/guile-1.6] > app-installer-tool install guile-maemo_1.6.7.1-1_i386.deb Selecting previously deselected package guile-maemo. (Reading database ... 20 files and directories currently installed.) Preparing to replace guile-maemo 1.6.7.1-1 (using guile-maemo_1.6.7.1-1_i386.deb) ... Unpacking replacement guile-maemo ... dpkg (subprocess): failed to chroot to `/var/lib/install': Operation not permitted dpkg: warning - old post-removal script returned error exit status 2 dpkg - trying script from the new package instead ... dpkg: error processing guile-maemo_1.6.7.1-1_i386.deb (--install): there is no script in the new version of the package - giving up Errors were encountered while processing: guile-maemo_1.6.7.1-1_i386.deb failed Installation of guile-maemo_1.6.7.1-1_i386.deb failed, removing package guile-maemo. (Reading database ... 20 files and directories currently installed.) Removing guile-maemo ... dpkg (subprocess): failed to chroot to `/var/lib/install': Operation not permitted dpkg: error processing guile-maemo (--purge): subprocess post-removal script returned error exit status 2 Errors were encountered while processing: guile-maemo Removing failed! [sbox-SDK_PC: ~/guile-1.6] > sudo -u install dpkg --force-all -P guile-maemo bash: sudo: command not found [sbox-SDK_PC: ~/guile-1.6] > dpkg --force-all -P guile-maemo dpkg - warning: ignoring request to remove guile-maemo which isn't installed. [sbox-SDK_PC: ~/guile-1.6] > dpkg --root=/var/lib/install --force-all -P guile-maemo (Reading database ... 20 files and directories currently installed.) Removing guile-maemo ... dpkg (subprocess): failed to chroot to `/var/lib/install': Operation not permitted dpkg: error processing guile-maemo (--purge): subprocess post-removal script returned error exit status 2 Errors were encountered while processing: guile-maemo [sbox-SDK_PC: ~/guile-1.6] > app-installer-tool list guile-maemo 1.6.7.1-1 2388broken maemo 1.0 0 ok [sbox-SDK_PC: ~/guile-1.6] > ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
