Re: Discontinue distributing Maemo Bug Jars via email?
Hallo! During the MeeGo conference, I had one person request I stop sending out Bug Jars via email. Does anyone find receiving them via email useful? Shall I continue to send them via email or not? I do not have a problem with the emails, I would rather prefer to drop it from the planet, just because the device internal RSS feed reader is not helpful if I want to skip long text entries and I do read planet using this reader. Also generated content is not the typical blog content, thus posting it there might not where people expect it. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to optify in MADDE?
Hallo! Then why we went to maemo-optify path instead of modifying Debian build tools? I know it was a huge thread about optification, I didn't dare to read it. Neither want to start it again :) Location of application files is not only defined by the packaging mechanism. Part of the locations are defined by the software at buildtime (partly configure options), some may be hardcoded. In general one cannot be sure that after apckaging moves around files the application can find all of its files. Optification was a very late "feature" and getting software to run on the device quickly was a goal while SDK or device modification were not possible in that short time frame. So a solution was created that may not require the active support of the developer, by mobinf files and at the same time creating links from the old to the new location hiding the movement from the application. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N810, GPS and Java
Hello! > still having some trouble trying to put together an interface to the GPS > device > on the N810. Overall I need to retrieve the current location (not sure what > kind of data the GPS driver (or the gpsd) returns on the N810) that > eventually > I can feed into Google Maps API (or something equivalent) to show me > my current location on a map. > If anyone has ventured along these paths and has some suggestions I > would greatly > appreciate it. If existing apps are out there that can already performed > these > operations it would even be better so that I don't re-invent the wheel. GPSJinni sources contain for accessing the GPS via liblocation (and there is also some code to access gpsd via libgps) for N810 and N900 and visualizes most of the raw data returned. Contact me for details. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras-testing improvements
Hallo! I (still) suggest to formulate a vision statement, that should clearly describe the purpose of extras. This formulating should be the guiding line to define further detailed rules and to judge if a new suggested rule is in compliance to the existing vision. Since there seem to be two interpretations of the purpose of extras, this is IMHO really necessary to avoid that every discussion about a new rule or policy results in a discussion about the vison in whole. A vision statement should define a target/purpose and a strategy to reach the target. A possible vision statement for extra scould contain the following aspects: * We want to make open source software available for the maemo platform in the most convinient way for the user * We want to make it as easy as possible for the developer of open source software to publish his software to every maemo device owner. * We do not want that the over all user experience of owner of a maemod evice is degraded by installing and running open source software (hmmm, tricky, in fact I want to say that *other* application or not negativly influence by the new software and this does not imply anything on the quality of the software itself). * We want to aply mechanism that help the developer judge the quality of his software, the recepted user experience of the end user while using his sofware and want to give him clear hints how his software could be improved to better fit the device philiosophy and end user needs. > If we want an uncontrolled place for apps then we need the "extras-author" > someone suggested yesterday. There is nothing stopping us creating that. > But, if we do then my prediction is that Extras will be dead within 3 > months. > If there is a place where user's can look for "latest and greatest" apps > then > everyone will enable it, developers will stop bothering to promote their > apps > to Extras, and a short time later, everyone's devices will start to die > because the apps there are not optified, run down the battery, etc. The question is, what would be the purpose fo the extras-author? Is there a possible vision statement for extras and extras-authors that make them distinguishable? For me it looks like, extras-author is just extras without the tests. What would be the purpose? For me it sounds like a short cut for the developer to avoid the hassle with the extras QA. But this would just be a (not that good) workaround for the problem that current extras processes is not optimal. Should we not spend our time and energy to improve the extras process instead? If we have a faster walk through for applications in extras we do not need a "hot new stuff" repository. If we automate tests, too. If we handle updated better, too. Perhaps extras and extras -author have the same target but only different strategies? I think we have set up an initial version of the extras proces. Now we have gained some experiences. Perhaps it is time (since we also have that mameo<->MeeGo merge Thing underway) to openly discuss the process, optimize and refine it. This would would also move us into a stronger position while discussing future MeeGo infrastructure because we not only do have the experience but also we have already learned something from them and are already int he "optimize" stage :-) -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras-testing improvements
Hello! > myself. But poor quality applications reflect badly on maemo.org > community as well. Do you want to be part of a community which is known Right. But for this we have rating and another repository does not really help solving this. If this results in extras containing 100 5 star rated applications and 1 one star rated applications in some other extras-authors repository Nokia is not not happy either. Who is to blame? If on the other hand if the repository is full of one star rated application who is to blame, too ;-)? Another repository is just hiding things but it does not make applications better or the repository containing more applications (which seem to be unsurpising interests in extras). As Graham stated there are other ways required to improve this. > for its low quality standards? Notice that the current extras-testing QA > requirements are quite low: I agree. I don't thing that the requirements are a real problem. But the current process seems sub-optimal. Possibly the goal of the extras repository has to be clearified (not changed!). If the process gets simpler we may even be able to add further checks (not blockers). I especially would be interested in automatic tests if possible. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Screenshots to user installable GUI packages in extras-testing [was Re: External Repository and HAM]
Hello!
Sorry ? I don't follow. We don't have the luxury of natural selection and wait
for applications to actually cause damage to crystallize a score on a web page
(which is BTW not even visible from the Application manager). I do believe
that Extras as default was given the green light by Nokia in good part because
the extras-testing concept proved as a working (albeit not perfect) measure to
increase quality of software encountered by end users.
I think initialy (and hopefully still) extras was not about good or bad
software, its was about software that does not break your device (and
does what it told). That is what QA must try to target. Comments about
usability, spelling mistakes improvements are good (and I personally got
some good hints by such comments, so I do not want to miss them), but
that should not avoid applications getting into extras.
That was (AFAIK) the initial vision (and if it is not somewhere
explicitely state, it should). Everything else (apps egtting better and
better) is an result of personal motivation, positive/negative feedback,
karma, voting etc... To get such positive feedback the additional limits
for getting software into extras should be low (since we want to have
the as much as possibly *working* applications in extras). Note also
that the numbers of applications in extras is somehow possibly also a
obvious, measureable marketing relevant information, while quality is
not that clear - so for Nokia is possibly not the only goal to only have
excellent quality application in extras. As always things are
complicated ;-)
I would accept this as a valid argument IF you did not have the option of
installing applications from downloads.maemo.org. But you do. If you go that
route, you will never ever see the application icon - the screenshots have the
same purpose there. Plus, for better or worse, Nokia is moving in this very
direction of installing via browsers.
Yes, it is wise to have a screenshot, but if the application is not
downloaded because of a missing screenshot this is a problem for the
author, but not for Nokia neither for the community ("it does not do any
harm to the end user"). Of course we are also interested in a good
repository and this includes screenshots for asmuch applications as
possible, but to get as much developers interested and have a very low
entry barrier it may be more wise so send a regular friendly reminder to
the author or make the applkication disaapear from the front page
earlier (within a definded process) instead of making this a clear entry
barrier, makeing the author stop working for maemo (MeeGo).
--
Gruß...
Tim
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: External Repository and HAM
Hello! Graham, (et al.) I appreciate your concern about shared resources, but it seems to me that you are overstating the problem. As an example, I quickly checked the repository lines in sources.list on several different Ubuntu boxes I support. One box included a third party repository for TOR. Another included third party repositories for Chromium and Scratchbox. It seems as if there is a long, well established tradition of supporting multiple repositories. These are possibly not the best examples for using shared resources. For me essential shared resources are libraries and base functionality like: * libcairo, libpng, tiff, gif etc.. * qt, gtk, tcl * pearl, phython, ruby Scratchbox (on my debian system) does not bring own versions of such shared libraries so this is not a problem. And I assume that THOR neither does. The problems come not with multiple repositories but with different/same/differently build versions of the same resources. This results in application A 1.0 from repository A also offering shared resource a to use shared resource a' (which is a variant of a) from repository B and which is subtle different and breaks A 1.0 (without author of A 1.0 even knowing, because he does not use repository B). Now trouble starts between the suppliers of both repositories to sort things out (but I need.., but it must not...). Things even get more funnier with 10 repositories ;-) In fact this must highly coordinated (and is IMHO one of the reason dtsributions exist). Yes, it is possible that two different apps might rely on libraries with the same name but different features, but if this is a significant problem, then I would expect bug tracking systems to rapidly uncover and lead towards a proper resolution of the problems, and community pressure would lead towards the two different application repositories to resolve their issues or see one of them fall out of favor. Hmm, possibly yes (but I doubt the end user would use the bug tracker as much as it must to sort things out), but it takes time to sort things out and to change and meanwhile the bad image of the device and it environment is already there. We should sort things out in one repository, this is much easier and better than making customer first fall into the pit and later on getting him out of the pit again... The simplest looking way is only simple until the next corner ;-) -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: External Repository and HAM
Hallo! >> And the most important things which guide my decision, is that >> currently, many thumb down make me angry as there was wrong vote, and >> the fact that i m passing more time to package than to develop didn't >> help. > > If the votes are wrong, complain. If they are not, then fix them. Don't > split the user's experience. Why do you think the answer is to make every Where? I may know the right name, but if I would not, where on the page is stated where I can complain? Where is the "This vote is wrong, please change it" button? I made two bugs about improving information in similar cases, but last time I looked there were not handled. Is there anyone working on the interface to improve/fix? > Feel free to propose improvements to the process. See above. Are there resources to work on such topics, how big is the change that such problems will be fixed/discussed/improved with in lets say 1 month? > This is really the point of Extras. The QA process is supposed to be > lightweight and just to verify that the apps don't "damage" anything (i.e. From the developer view this does not feel lightweight (or better fast) enough. There were discussions about fast tracking, reducing the time limit, the number of votes etc, there weere even strong complains... but I feel not much happend :-/ -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: External Repository and HAM
Hallo! > The mass-downthumbing people might see is just a temporary (?) solution to > > optimize testing resources. The idea is that it should be immediately > visible > that this package is NOT going to be promoted, so testers should not vaste From the developer view thumbs down without a explanation are a "no-go". With such (unavailability) of information I cannot be sure if the tester found a new bug, which he did not state, or just found an existing bug (or is just collecting karma). Because of that I can never be sure, that my package goes through testing even after fixing all mentioned bugs. Please at least write a one sentence exmplanation for a thumb down that just give they keywords for already found bugs "e.g. something like, Thumbs down because of Bugtracker URL, About Dialog, spelling mistake as stated"). This should not slow down testing very much but avoid the developer feeling like he has just been hit by the spanish inquisition ;-) I would also be happy that while an application already has a thumb down that further people test it to find more bugs (until there is a real blocker like not beeing able to install the application). A sequence of found one bug - fixed one bug - found one bug - fixed one bug is very anoying (ith this limited testing resources (which should better be named "the people nobody knows of that do excellent work" :-)). > On a side note I would make screenshots (where applicable) also mandatory > for > promotion to -testing, on the same grounds as a bugtracker, but the > ideas/message counter is in the red zone already, so I'm going to stop > here... :) As far as I now screenshot are part of the download page and just can only added after a download page has been created. A download page is created *after* promoting the application from extras-testing to extras. This is IMHO a bug in the process (if there is not another way I don't know about). -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Hallo! >> What happens to apps (especially those with Qt dependencies) _currently_ >> in Extras, i.e., how will they get to the fremantle1.2 Extras repo ? > The Qt apps are currently blocked from being promoted to prevent issues. > The fremantle-1.2 repository will probably need to be 'legacy' clean. Qt > 4.5.3 is not available in Extras and will probably not be available on any > repository enabled by default on the device. This means that applications > depending on this, will not work. > > Those applications need actual changes to work with Qt4.6 iirc. No, what happens witht he packages currently ine extras? * Will they automatically moved to fremantle-1.2 Extras? Sounds like this is not possible. * Will they automatically rebuild against then current SDK? f yes, how do we find out it will work? * Will fremantle-1.2 Extras be intially empty and we have to get all packages in it again trhought he extras-testing process (Ooohhh, n, that will take ages!) -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: HOWTO: Query installed application
Hello! Take a look at libapt-pkg-dev,. You can also check the sources of PackageView. I'm however unsure if you can access the icons using this way. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Check is app installed from another app
Hallo!
I'm just wondering what's the best way to check is an application installed
from another application?
perhaps doing a system("dpkg -l mypackage") and checking the return
value is good enough?
lib-apt-pkg offers programatic access to the local repository. However
it needs some setup and my be thus a little to big" solution.
--
Gruß...
Tim
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: How to destroy your community
Hello! > Please show up at the next monthly sprint meeting and take some tasks to > improve things then. How much time and energy are you willing to pitch in > personally? (While not address to me). That is too simple. I'm developer, spending much of my free time in maemo related developing. I must be able to hint at problems and make suggestions without realizing them by myself. I know that this is a common open source problem (people always only want to make the nice stuff). But in the end people were nominated/paid/raised their hand to be responsible for something. I must be able to address tasks to these people, because for various reason they are or should be experts. And as long as these people exists I do not want the hear "come there and offer help" but I want to here "Bullshit" or "I put it on the TODO list" (and of course lets further disccuss). If positions are vacant or people have too much workload or there are urgent things to do adn help is required, this should be addressed, communicated and hopefully resolved (and also adressed to the community with request for help). It should also communicated if this breaks and TODO lists get to long to get handled anytime soon (something communities break at this point because all have ideas but nobody wants to do anything). Possibly I may take a job I feel confortable with in the end, but that should not stop me pointing at problems and increase the size of the TODO list. "Do it yourself" sound like a easy way to get rid of problems. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Aw: Autobuilder => ww.maemo.org
Hallo! >> This however may make my suggestion even more valid, making me not >> writring silly "i do not have trust in autobuilder" that fast, making >> admina smoking more cigarettes than before. >> > > ? I don't want to bother the admin of the system by "Is it still alive" mails everytime autobuilder does not react in 10 minutes. You should spend your time to more important task than aswering my (and others) questions about the state of the system. > If you subscribe to the extras-cauldron-builds list, you could see that > there was a package severely stuck. I would see this as a short time workaround, but would propose a "live and short time history state overview" solutions as mid- to longterm solutions. Nevetheless the "workaround" should get a prominent state in the developer landing page (I now remember that you might haven given this advice multiple times before?). FAQ? > Ed promised to create a fix for buildme, so broken packages can't block > the queue anymore. OK. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Aw: Autobuilder => ww.maemo.org
Hello! > Hmm, I know tzhis is a hated question, but is the autobuilder for > fremantle alive? it is, seconds after sending the mail, the first OKs arrived. fine! This however may make my suggestion even more valid, making me not writring silly "i do not have trust in autobuilder" that fast, making admina smoking more cigarettes than before. Btw, besides hick ups the builder appears much faster now. That is great! -- Gruß... Tim___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Autobuilder => ww.maemo.org
Hello!
Hmm, I know tzhis is a hated question, but is the autobuilder for
fremantle alive?
At
http://maemo.org/packages/repository/builds/fremantle_extras-devel_free_source/all/
the latest build is from ~22:00 UTC yesterday. I have uploaded a number
of packages around 24:00 UTC+1 but non of them appeared.
I know that in rare circumstances there are long build that make the
Autobuilder *appear* to hang, so I would like emphasize on another
aspect (while still beeing interested on the state :-)).
For me the natural landing package as a developer is
http://maemo.org/development/. That worked good in the past but for me
it seems some (new) important features are not visible available on this
page, namely the everything around building, uploading and promoting
packages.
Examples:
* http://maemo.org/packages/ does not seem to be linked on the landing
pge, while it is very important for my day to day work as a developer.
* I would expect some helthness state about the various autobuilders
here. It would be enough to have some green/red signal here. Other
infrastructure aspect of course should/could be placed here, too.
* I would expect some process image somewhere in the upload image,
stating various aspects of infrastructure and packages evloving from
extras-devel to extras.The text is here but sometime an image is better.
Giving state a clear name that reappears under .../packages in texts,
buttons of course would be a winner...
* I just promoted a package to extras-testing (the button was only
called promote, extras-testing was not mentioned) and I expect QA to
check for the existance of a proper packgae for maemo5 on downloads
including a screenshot. While scanning the documentation multiple times
I have not yet found out how I create such entry for maemo5 (I know how
it works for <=OS2008) and I assume that somewhere in the process it
wass created automatically (after promotion to testing?).
I can file a bug for every aspect,if some responsible person just says
("make a bug") but I think some discusssion may be worthwhile, too. If
this was already discussed elsewhere and there already exists a grand
plan/bugs, just tell me.
--
Gruß...
Tim
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-devel] List emails subject prefix
Hallo! >> So what if us who can get themselves a proper mail client just configure >> them to remove these [maemo-devel] droppings on our side? > Sure, there is such option too ;) > But I also read mails on N900 and Modest do not have such one ;( Neither thunderbird AFAIK. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Autobuilder build error (unmet dependencies)
Hello! What is happening here? [2010-01-20 10:14:11] fakeroot apt-get -y -q -o APT::Get::AllowUnauthenticated=1 install --no-remove libillumination0-dev libapt-pkg-dev https://garage.maemo.org/builder/fremantle/packageview_0.4.20100104-4/armel.root.log.FAILED.txt And: http://maemo.org/packages/package_instance/view/fremantle_extras-devel_free_i386/libillumination0-dev/0.1.20100115-1/ Is this an effect of the PR 1.1 problem and I have to rebuild libIllumination, too? -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hallo! > In sum, what is the upside of including anything but symlinks on the NAND? > IMHO, it should punt everything to /opt as long as it is needed at all. > > Thanks for maemo-optify, it makes things so much lazier^H^H...easier. :) Symlinks take space on disk, too. I'm not sure if they take a whole block or a part of it but there is likely a limit where a links costs more space than the data itself. Is this where the 2K come from? We also should keep care that we do not run out of inodes (which IMHO should not be a problem if we replace the real file with a link because that does/should not increase the amount of inodes). -- Gruß... Tim. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process for "middleware" (libfoo, python-bar) packages: some ideas
Hello! > I believe we can improve on this area: to have safer and optimized Do we have a problem? Does testing applications instead of enablers make us let problems go into extras that do not pass the extras criteria? > Let me give some examples of such possible bugs: > * A new version of libfoo is uploaded with unexpected ABI (Application > Binary Interface) changes. At the same time some application is > compiled against it and it works fine, so the package (together with > libfoo) is promoted to extras. OTOH, this new version libfoo does not > play well with the existing packages in extras, which will break or > even fail to start Yes, this might be a problem. Could we test this automatically by checking missing symbols of binaries against offered symbols of libraries (for hard linking errors). Not hard linking errors can only be detected by testing all depending applications? > * A new version of python-foo (some binding for libfoo) is uploaded to > extras-devel, but contains a serious flaw that makes it segfault when > calling method xyz(). At the same time, GUI application is uploaded > which depends on that newer version, but does not use xyz() at all. In > this case, the current QA checks would basically allow the application > and python-foo to enter extras, but some future application which > tries to use xyz() will segfault, blocking it from entering extras > until python-foo is fixed. Yes. There were discussions in the past how to handle, manage, maintain libraries that have multiple dependend applications with different maintainers. I do not remember that a solution was found (besides "talk to each other", "make a bug") > * Require (or strongly recommend) *all* packages to have at least some > sort of unit/functional testing. In fact, most packages imported from > Debian has tests, but what usually happens is that they are disabled > so the package can build on scratchbox. IMHO that does not solve above problems and such strong requirement will possibly keep a number of libraries ot of the repository (including mine). Possibly even once that are part of the platform? In fcat to solve above problems this would mean that I do not have to test my application but I must test in my application if all functions I call from foreign code is available and does what I expect it does. Of course if I would write tests for my library they would always pass and still could break applications anytime. If I drop functions I will drop the test, too. If I change the meaning of an function I will adapt the test, too. Same goes for applications. You want to test interactions between applications and libraries so you must have test cases for this interaction. And while I apreciate automatic test suits I and most other small problems cannot manage this because of lack of resources. I likely find 90% of my bugs using application functionality tests much faster (doing server development in my job things are different...). > * Have some way to run these tests automatically from the package > sources when uploading packages to the autobuilder. > * Exercise installation of packages (maybe using piuparts? See > http://packages.debian.org/sid/piuparts), if possible on a real > device. I think the maemo version of lintian does/will do such stuff but not by installing but by checking package for known failures. A working installation is not good enough. You would need to start the application but how do you check that it works? We should solve easy problems first and extending such mechanism possibly fixes/finds more problems faster? > * Test disk-full conditions, and randon errors during package > installation of packages from Extras. Disk full on installation is a problem of the packaging mechnism and normally not a problem of the package (if it does not run space using scripts on its own during installation). For checking disk full conditions on the application you must install it, run it and trigger its writing functionality. To do this automatically is somewhere between difficult and impossible. > * Promote usage of ABI check tools. Yes. As mentioned above. I would suggest to the tester to collect reoccuring testing failures they have the feeling that could found automatically and contact the build masters in such case (by filing an bug/enhacement request) - if they are not doing this anyway already -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA Process for non user/* packages and how Application Manager handles upgrades (was: Re: extras-devel -> extras-testing auto-promotion not working?)
Hello! > That's what is happening at the moment with python-osso. [...] > So unless someone promotes a user/* package to extras-testing that has > "Depends: python-osso (>= 0.4.0-0maemo2)" , python-osso will remain > broken on extras & extras-testing. That also happend for me recently with libIllumination even in extras-devel! A bugfix does not get installed by the device. Is this the same effect? If yes, thrilling is that I have a n:1 constellation where multiple application depend on the same library, where the applications do not have any dependencies on each other. So I must increase the version and force a rebuild with a higher dependency for *all* application packages? If I miss one, funny things will likely happend, with some people having the new version and some the old. The effect occured recently. I assume because before libIllumination had a user/* category (which was identified as bug). That all sound very broken... Imaging this happening for the community based hildon add-on controls library, which is likely widly spread in future. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Aw: windows garbage like raster
Hello! This sounds possibly like an effect I had with my application (not using gtk but only gtk theming) with the pre-production device firmware but that seems to have dissapeared with the new, production firmware. -- Gruß... Tim___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Package does not end up in DIABLO extras-devel
Hello! > Packages are starting to show up in diablo's repos now. I will try a look > into this and make sure things are working as they should be. I don't want to > restart any services or have any unplanned downtime so I am not going to be > intrusive, just poke around and see if I can find any obvious issues. While I got success mails for uploads of a new (lib)illumination version, it still does not appear in the extras-devel repository (http://repository.maemo.org/extras-devel/pool/diablo/free/i/illumination/). For fremantle everything works as expected. It seems that at least for me something is still broken in the diablo autobuilder process. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
Hello! The following is a rant about XB-Maemo-Upgrade-Description with some suggestions for improvement... Change Log handling (at that time for the downlaod page however ) was discussed before! See: http://www.mail-archive.com/maemo-developers@maemo.org/msg16160.html -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Follow up from QA meeting on IRC
Hello! That all sounds OK. One other point that just came into my mind. Is it possible (I havn't yet promoted something) to leave some message to the testers while promoting application to extras-testing (or even leave permantent comments regarding testing as part of the application description)? Reason with concrete example: One of the testing requirements is that more than normal power consuming applications should give a hint at first start. In this case tester need to know how first start is detected and how the application can be made to think it was first started. In my case I would realize this with a hidden configuration file (~/.blabla.xml) that has to be deleted. This must be known by the tester. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Mails about ratings from "Downloads"
Hallo! I'm interested in such mails (AFAIK I was possibly even the person who requested the feature ;-)). I'm intersted in getting to know that somebody rated my application since I'm intersted in improving the rating of my applications. Getting a mail makes it possible to react on ratings (without regulary polling the web pages which would be a pain for >10 packages) and for example contact the author to get more information about the reason of his rating and to find ways to change the application so that he would increase his rating. There were several case where I was able to fix/improve the application and get a higher rating in turn. I would be intersted in getting more information in the mails (currently I walk the link to get more information). So please do not remove this feature (but possibly make it configurable per user if other people are not interested) but enhance it! -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: read XML files
Hello! > Is there a way to read XML files in the Maemo distribution ? The GNOME XML library is available (should be libxml2-dev, libxml2). See also http://xmlsoft.org/. It is also possible that QT has a XML library, too (I'm not using QT). > If not can you recommend one available in extras ? > If not can you recommend one ? libxml is a C library. I'm happy with it, but a C++ (QT) library might have (or might not) an easier interface. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
Hello! > Except how do you try to prevent abuse (whether intentional or > accidental)? At least with the version number you've got some safety > check (although it is in no way comprehensive). It also requires more > changes at more levels (I bet), so harder to implement. I think it is time to decide (again?) if we trust developers in their atempt to get their software/package into extras or not. There are some points in the decussion about handling of extras-testing extras propagation for which we should find a simple solution for - once we have finally (for some time ;-)) decided about trust. It looks to me that currently we are randomly hopping form the "trust" to the "as stable as possible" road back and forth and have to discuss/find (implicitely) the road we are on for every sub problem again and again. We likely agree that either extreme is not good for different reasons, but we havn't a clear definition for the middle way either (it is dark out there even in the night on the highway). We defined some criteria for extras which I find astonishly lax in some parts (but since I likely will have advantages for my software because of this I will not complain ;-)) and on the other hand sometimes it looks like we are defining fort knox. Perhaps we have different definitions for the trust and stability of one package and trust and stability of the repository in whole (breaking dependencies etc...) but then lets clearify that. Breaking a package is not nice but not really a drama for the community, breaking the repository or large parts of it will be a far bigger problem. (Perhaps we should also define what we expect the average user to be able to handle. Since such assumptions have consequences, too). Again: What is our vision for extras? P.S.: Don't trust my version numbers! Trust my checkbox choice! -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 - Playing sounds from Qt
Hello! > Isn't it a bit of an overkill to set up an entire GST pipeline just to > play > a blip sound? Yes, but if you want to play your own sound or any sound on the filesystem this seems the way to go (libcanberra is for predefined sounds for predefined events). Lower level ways are likely forbitten, higher level ways likely require more code. > Is there something more lightweight? You can use "playbin" (or playbin2?) for simplifing the pipeline building process. That still makes it a number of lines of code (but of course you will wrap that into a helper method :-)). -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 - Playing sounds from Qt
Hello! > I tried using libcanberra, and my example works on the desktop, but when I > move it to Scratchbox, I get a CA_ERROR_NOTAVAILABLE when I call > ca_context_play(). [...] > Should I be doing something different? Is there a better API? What do > linux game developers usually use for playing short sounds? Can anybody > provide any examples? AFAIK, libcanberra is mainly for triggering playing system sounds (from some system sound theme), like in "play the sound the OS defiens to be played when I pressing a button". For playing any sound (and much more :-)) you can use the gstreamer API. take a look at: http://maemo.org/development/sdks/maemo_5_api_documentation/ Section Multimedia APIs -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo Summit /opt BOF notes...
Hello! > * The autobuilder will run maemo-optify after the build, UNLESS a > control field says not to (or the package already uses /opt). > This WILL create bugs which package maintainers will need to fix. > ACTION: mvo to liaise with jeremiah & X-Fade Since there currently seem to be problems with maemo-optify we later in the discussion decided to make it opt-in for around month(!?) to be able to find bugs in a more controlled environment, then make it opt-out afterwards. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo Summit /opt BOF notes...
Hello! >> Just a side note, since it was multiple times mentioned in the BOF that >> Bounce Evolution is already optified. On my device deinstalling Bounce >> freed around 50 MB on "/". For me this is a strong hint that Bounce is >> either not optified or that installing it on the device did not what was >> expected to happen. > > Hmm, `du -h' says /opt/bounce takes up 21.7M on my N900. > > Maemo version: 1.2009-41.10 > Bounce version: 1.0.0 > > There's nothing but icons, .service and .desktop files installed outside of > /opt according to /var/lib/dpkg/info/bounce.list. Right. Reinstalling the application did not reproduce the effect. My "/" however was closed to ful, the number of applications installed did not match the fullness of "7" and deinstalling bounce did increase the space by 50MB. Also I sure that there is no other single application I could have deinstalled to get that much free space (and I have not installed and einstalled that much applications anyway). Strange, very strange... OK, I correct my self until someone else with full "/" and bounce installed can reproduce it (and makes further analysis before deinstallation ;-)). -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Getting package with lower version into extras-testing
Hello! > Exactly. If I upload e.g. 0.5.6 (stable) to extras-devel where there is > already 0.6.0-alpha9 (unstable) the users still will get the unstable > version which is exactly what I want. In fact I don´t need to have the > stable version in extras-devel at all, but I have to put it there first > to be able to promote it to extras-testing. Correct. Currently to get to extras and extras testing you must for upload to extras-devel. > I never said I want to put buggy software into extras-testing. I want to > put stable software into extras-testing! OK. Does not change anything in the context of the discussion. > I think extras-devel is exactly for that. It´s the first step for a new > package. So unstable packages should go there. Right. > Now, once my 0.6-alphaX version will reach let´s say 0.6.0 and I > consider it stable, then I´ll promote it to extras-testing. There it > will replace the 0.5.x versions and testers can test it. Once they think > it´s stable, I´ll promote it to extras where it also will replace the > 0.5.x versions. [...] > In this way there is only on package and the users decides which version > he wants. If he has enabled extras-devel he´ll get the unstable version, > if he has enabled extras-testing he´ll get the testing version, and so > on. All well thoughtout, but one problem: If you later on find a bug in 0.5.x and you will upload 0.5.y (where y>x) to get that fix into testing, at least in extras-devel nobody will be able to download it, because the application manager wil never show it. It will only and always show 0.6-alphaX. And if you have 0.6.0 in extras-testing (where it possibly stays for lets say one month) and in the mean time you promote your 0.5.y fix (because it works), no tester will see it in the application manager either (they will only see 0.6.0). They all would need to download and install it manually to the device (and you have to support this downgrading in your packages). Btw., IMHO direct uploads to extras-testing for bug fixes will not fix this (likely suggestion to solve this). > I will go that way if it´s the way to go, but I would like to understand > why my way is wrong. I think it makes more sense to have only one [...] > Sorry to be so persistent, but I still don´t understand why I should > have two packages. No problem. Is it clearer now? -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Getting package with lower version into extras-testing
Hallo! > Thanks Graham, I guess I´ll have to do it that way then. Only I still > don´t really understand why. I mean, why is it not ok to just upload a > package with a lower version number to extras-devel? I could then > promote the stable one into extras-testing and the unstable one could > remain in extras-devel. People do updates with the application manager on extras-devel. If there is a package with multiple version in the repository, application manager will only show and allow update to the packages with the highest version number. A repository togetehr with the application manager does not work like a file system. Also if a device has already downloaded a package version with higher number, placing an package with lower version number will not result in an update on the device. So why should one upload a package nobody will ever see or get? Depending on upload and download time different things will happen on the device. However you now clain that extras-devel is a staging repository for extras-testing and extras where you want multiple packages version where different package version go into different target repositories, so above should be allowed. I would say: No. extras-testing is not a target repository it is only a transitional repository where packages should be placed because on wants them to get them into extras. So packages that are placed into extras-testing should be of the kind "I think it is bug free, you, too?" and not "I know it is buggy, just take a look at the future" (in fact QA people will take a look at extras-testing and will test sofwtare that is known to be unstable). I would suggest to give "next stable version but currenttly still buggy" a special new package name like myapp-unstable or myapp6 (where 5 is the current version) (and keep this version in extras-devel). This was already suggested and sound much cleaner. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo Summit /opt BOF notes...
Hello! Just a side note, since it was multiple times mentioned in the BOF that Bounce Evolution is already optified. On my device deinstalling Bounce freed around 50 MB on "/". For me this is a strong hint that Bounce is either not optified or that installing it on the device did not what was expected to happen. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Packaging help
Hallo! You need two packages with different control file, one for diablo and one for fremantle. You can use any (generation) tool to simplify this task, but on upload the packages must have different control files containing different dependencies. AFAIK You cannot upload the same package to diablo and fremantle autobuilder and fix the control file on the server depending on the results of the configure call. If you want to offer packages for diablo and fremantle to might thus increase your packaging efforts. Offering mutiple packages I howevr do unsteeed your wish to be able to do such thing :-) -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
Hello!
>> Other thoughts included:
>>
>> * Use of /opt is perhaps now a QA requirement for Extras
>> * Can we somehow add a /opt check into minimae/maemian? Is it
>> possible, and is it sensible?
>
> Please recall that maemo5 is not the only maemo. Maemo4 is the latest
> availble for N800/N810 and maemo2 is the latest officailly available on
> 770. Many packages can compile from same source for all versions. Don't
> add artificial obstacles to force developers to make their packages
> incompatible with older versions.
I also would like to request a solution that does not make packages
differ from diablo or Mer. Up to now I was able to have the same
packages for all OS versions. A solution that requires me to have
different packages for Fremantle and "the rest", where the differences
are purly textual exchanges of "/usr" with "/opt" (which can possible be
automated as shown by maemo-optify-deb) creates additional efforts for
me (and likely other people packaging software). While the reasons for
this are well argumented and need not to be discussed they have their
origin in a technical defiency than in a planed architectual or design
change and thus possibly should be handled by the package.
I would kindly request a solution that:
* Either changes packages automatically by the autobuilder. A
functionality that seems in principle available. I have no problem with
explicitely activating this feature from within the package if the
trigger is for example an additional marker file that is ignored by
earlier versions (and can be evaluated by Mer any time).
* If a simple trigger ("Use /opt!") is not sufficient because the
underlying algorithm is not good enough I also have no problem with an
additional file that states (sub)directories that do not need to be
placed under /usr and then can be switched in the package scripts by
maemo-optify.
Currently I place data like icons, images etc... under /usr/share/...
using configures "$(pkgdatadir)" to hand over a compile time define to
the application do be used as search path for application data. With he
requested move of application (and/or application data), will such a
define still work? Will maemo-optify exchange the call to configure to
explicitely set the non-default position of the package data dir to
/opt/...?
Will it exchange
configure --prefix=/usr
with
configure --prefix=/opt
or something like
configure --prefix=/usr --datadir=/opt
(not sure if this is --datadir or --datarootdir...? Currently it does
use links to fix this (so it should work without patching "rules"), but
it looks like using links is under discussion, too :-/
If not, we are to different packaging anyway I fear...
--
Gruß...
Tim
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Problems with the fremantle autobuilder...
Hello! > unfair to users if the version is not changed. So if I understand you > correctly, you are saying a failure to build is not reason enough to > change the version number, with which I agree. But if you change the Right. Fine :-) > code somehow, or change the packaging, so that it can build, then > perhaps change the version number? For what purpose? Nobody but me and the autobuilder might know what I have changed (and somthing I must have changed else it would not pass this time). Isn't that just versionities? >> Once package P version X has been successfully built then a >> subsequent attempt >> to upload package P version X should be rejected. > > Exactly - this is the current behavior. and coming back to the original question... If there is already version 1.0 in the repository I cannot upload version 0.9 either, because it would build but nobody who see it by default (tools would always take the highest version available). -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Problems with the fremantle autobuilder...
Hello! >> I suppose that if a package is rejected, we can upload it with the >> same version number ? Requiring to increment the version on each >> failed/rejected upload would seem strange IMHO :) > > Why would you want to upload a package with the same version number? > Incrementing the version number is the purpose of the version number, > so of course you would want to change the version number every time > there is a new package. You should be able to use the same version again and again as long as the autobuild does not let the package pass. Why increment the version number for building atempts nobody will ever see. The "check in" (to speak in version control speach) occures if the autobuilder let the package pass. So I can upload badthing-0.1 as often as I like up to the point autobuild builds, for my next update I must use a higher version number (I cannot replace packages using the same version and smaller versioned packages will enevr been seen by anybody). This was the original question and AFAIK this is the way it is and should be implemented. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo 4.1 GTK button
Hallo!
> I am trying to using a button only with image from stock, but i cannot
> success, the button only show text like "Preferences" instead of showing
> image. Does anyone knows how to get button with only image?
This feature (showing button image besides textual label) is by default
switched off under the maemo version of Gtk. This likely has been done
for space reasons.
This means that something like:
bool GetSettingsBoolValue(const char* name)
{
GValue gvalue;
GtkSettings *settings;
settings=gtk_settings_get_default();
assert(settings!=NULL);
memset(&gvalue,0,sizeof(GValue));
g_value_init(&gvalue,G_TYPE_BOOLEAN);
g_object_get_property(G_OBJECT(settings),name,&gvalue);
return g_value_get_boolean(&gvalue);
}
returns false for "gtk-button-images".
--
Gruß...
Tim
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: I can't get the autobuilder to work - Please HELP
Hello! > I an trying to submit my application to extras and am running it > through the autobuilder. I get the error: You need to define build-depends in your control file. You curently do not have any and the errors suggest that you at least need a dependency on lib-gtk2.0-dev. Build-depends define which packages will be installed befor your packages gets compiled. By default only a small set of essential packages will be available in the build environment. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Some DBus related questions
Hello! >> The problem is, that I'm not an Gtk application. So there are IMHO two >> possibilities: > > I assume you mean you don't use the Glib main loop. Gtk is not needed > for D-Bus communication. Correct. That was inprecise wording >> * Generate a separate thread that uses a glib main event loop and try to >> get libosso and libconic to run using this event loop - communication >> with the rest of my application using thread synchronisations. Would >> that work? > Maybe that would work, but it's certainly a horrible hack. Why? Glib allows to create additional main event loops, libosso explicitely allows to set an event loop. If this is a hack, why this APIs? > I think the simplest solution is to use Glib main loop in your program. > Otherwise you would need to hack the libraries to work with your non- > Glib main loop (which is not impossible, but quite a lot of work). Glib > main loop is like the GPL, it contaminates your program :) I don't want to. I'm having my own GUI library, why should I use GlibMain loop? And finally, if I would be writing an QT application, would you force me to use GlibMainLoop, too ;-)? What is the masterplan for future OS versions that will integrate QT better? That does not sound reasonable. There must/should be another way. IMHO the dbus is a perfect platform and language neutral way to communicate between processes, why should I forced to use a wrapper library that restricts me in my choice of tools? Why do not publish the dbus interfaces, and instead write wrapper librarys instead (of course it is OK to have both. I have no problem with having additional efforts If I do not use Gtk). What about testing any of the dbus interfaces under scratchbox. Is there a way? -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Some DBus related questions
Hello! A few questions about DBus-based features under maemo. I would like to enhance several applications with the following dbus stuff: * Show list of available networks in WifiInfo using dbus calls (because querying the kernel interface directly seems to interfere with the "normal" operation). * I would like to get information about current network connectivity and trigger network connectivity on demand. This can be implemented by using libconic. * Later on possibly connect to other services and get other events... The problem is, that I'm not an Gtk application. So there are IMHO two possibilities: * Generate a separate thread that uses a glib main event loop and try to get libosso and libconic to run using this event loop - communication with the rest of my application using thread synchronisations. Would that work? * I already have a dbus event loop running as part of my internal event loop. However this is not glib main-loop based, so I would not be able using libooso, libconic and similar, but have to get the direct dbus calls from their sources (having to adapt code every time the dbus interface changes). So here are the questions: * Does anybody have experience with non-gtk applications and can recommend on of the two ways? * Is there any code for accessing the list of wlan access points via dbus? * How can I develop and test against thus dbus services using scratchbox developemnt environment. Are there fake-services configured that can be started and return "enough to test" results. * Is LibLocation also DBus based? How can I access GPSD from non-Gtk applications? How can I test accessing the GPS functionality formt eh scratchbox environment. Is there also a fake-service? All information is based on Diablo reference manual. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder for OS2006 wanted?
Hello! > Are there developers out there who will use the autobuilder for OS2006, if > it is available? Do you think it is worth the trouble to set it up? Will > it make supporting OS2006 easier for developers? > Please let me know what you think. I would like to support my software for all OS version where there are still people requesting packages. For my type of applications this is currently not a software problem. The only thing I'm aware of, is that I have to adapt my packages to the different naming/versions of packages. AFAIK this can be handled by using "|" in the dependency rules. So as long as I can use one package for distributions I'm in. However I have difficulty to decided myself which OS version this are. There were indivudual requests in the past. Downloading statistics are likely the right way. If you support more OS versions note hover that I would like to have a way to upload a package once for multiple OS versions (I'm currently using the web interface, but AFAIK dput need one call for each OS, too) :-) -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: WM and bad position and size of non hildon apps.
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> X-Sender: [EMAIL PROTECTED] Received: from 149.239.206.50 [149.239.206.50] with HTTP/1.1 (POST); Tue, 22 Jul 2008 15:01:55 +0200 User-Agent: PING e.V. Webmail/2.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Hallo! > Hi Marius, > Ok, I apologize, but the previously picture wasn't very representative. > Please, look this one: > http://www.gnuton.org/blog/wp-content/uploads/2007/11/qt4-on-maemo.jpg > This pic shows better the problem. Basically the non hildon windows > use the whole area set by WM. > I hope to be explained better this time. > I aplogize again. > Thanks. A number of information that might help you: * The window manager resizes all top level windows to the complete available area (minus top and left bars). Thiswill also be done, if the window sets limits for minimum and/or maximum size. They will be ignored for top level windows (or windows, that are marked as top level). So your application must be prepared that the top level window will be resized. It must draw the complete window independent of the expected or actual size (which is normally realized by allowing all top level window to be resizable). * The top level window frames are not drawn by the window manager but are part fo the Gtk theme of the window content (Full screen windows just don't draw this frames). Just like a button has a frame, the window content itself in this case has one, too.If you want these frames you must read the image data from the Gtk theme and draw them yourself. I have done this for the libIllumination applications. You are right, ob would expect that this is the job of the window manager. -- GruÃ... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Porting a C program in Maemo
Hallo!
> Can you start by defining what you want when you say "stuff would be
> shown on the Maemo (2.2) screen"?
>
> Do you want the text in a dialog box? As a text box? You saw it on the
> terminal so it got somewhere.
>> printf("%d. Hail to Kernighan and Ritchie \n", i);
To clearify:
* All standard output like printf or similar (or std:cout in C++) by
default will be printed to the terminal this application is started in.
So in your case, the user of the Device has to open the xterm first and
then start your application. If you would get your application listed in
the menues and start it you would not see anything because you do not
have a terminal attached.
If you want to open your own window (and do not rely on the user opening
the xterm window first) and print stuff there there are several options:
* Write a wrapper script for your application and make that wrapper
script open the window first (you might need to work around the DBus
application helth probing).
* Write a shell script and use a package like dialog to show text
(however I thing dialog is not available on the device). Dialog offers
you command line application that create simple dialogs that can be
opened from a shell script.
* Write a GUI application using a GUI library like GTk or similar. Note
that this will be very different to your initial C program but is the
prefered way.
Besides C you can also use c++ or python, which are also supported - but
the principle solutions are the same.
You can also use Curses for nifty console output but you wll still have
the problem that you require an open terminal first.
I would suggest to take a look at the maemo tutorial andthe various Gtk
tutorials that give you an introduction to Gtk programming.
--
Gruß...
Tim
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo.org/downloads automatic updates from Extras
Hello! > Personally, I'd rather downloads.maemo.org used one fixed system and > it was up to tools like mud to pull out heuristically derived data > from upstream and coalesce it into the simple format. This is only an option. If you ask me I would drop the magic and enforce the usage of one solutions. >> However many other formats with same or similar content are possible... > Indeed. TBH, I wonder whether another header would be sufficient in > debian/control? We've already got XB-Maemo-Icon, adding > XBS-Version-Changes or something could be sufficient. Is there any > need for anything other than the last modification? I proposed a concept holding history because the original changelog files have history, too. Of course you are right, for just showing the latest changes a header is simpler and sufficient. However the solution is in consequence not (easily) extendable and possibly useful only for this exact purpose (which is not bad per se). So: is there any reason to have the history as part of the package, for example do we plan to be able to browse through the history on the web page? Why does debian keep history? -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo.org/downloads automatic updates from Extras
Hallo! > One enhancement I would like to add is automatically update the 'Changes > in latest version' field for the entry in downloads. I would like comments That would be nice :-) > from the community on how developers should supply this information. > One option would be to fetch it from the changelog. Problems here are that > there aren't many packages using a changelog at the moment and we would > need to filter out the real changes from the packaging revision updates. The debian package changelog describes changed to the package made by the package maintainer. If maintainer and developer are different a changelog entry for a major relase could just contain "New upstream version" - which would not be that helpful :-/ Also normally new package revisions would generate an entry in the changelog, however the package would have no visible change - it would just fix bugs in the packaging or in the software (which however could be relevant for some users!): Another option would be to use the ChangeLog of the original source package - this would contain upstream documentation to changes in the original software. You would expect to find new features there. However upstream information might contain information of varying detail. I have seen packages that list a huge number of even internal changes - mor elike a developer blog. So this source may also not be of best quality, too. Another problem is that the ChangeLog is "owned" by upstream, the maintainer can/should not change it. It amy also not be scanable because of varying syntax. In the ideal world however I would always show the contains of ChangeLog for the current upstream release and I would show changelog of the package for package revisions > 1. So we can try it with these files and either put preasure on upstream or let the package maintainer fix/create these files or we can define a special maemo-specific file Maemo.ChangeLog that contains both information in a simple to parse, extendable file format (XML?). And to make everybody happy we try a fallback for ChangeLog and changelog if Maemo.Changelog does not exist - with improving magic over time. Simple XML file could look like: Packages new upstream version. Now plays funny sound on start. However many other formats with same or similar content are possible... > Another option would be to let the developer enter this data while > promoting the package to extras. We could add this step to the promotion > interface. IMHO a bad idea. I personally want to have the process as automatic as possible (OK testing is still manual :-/). This way I can choose time and place and tool and process and I'm not forced to use the web page (must switch to dput soon :-)). -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras-build diablo failed to compile Xournal
Hello! > But when it tries to actually build the package I get this errors: > > main.c:7:21: gtk/gtk.h: No such file or directory > main.c:8:43: libgnomecanvas/libgnomecanvas.h: No such file or directory > main.c:10:21: libosso.h: No such file or directory > main.c:14:32: hildon/hildon-note.h: No such file or directory You need to add additional build-depends for your packages for libgtk2.0-dev and likely other packages (note, that the package configure script does not check for the availability of gtk, otherwiese the problem would have been more obvious). You can see fromt he root log that the packgaes is not yet installed (only the packages containing the libraries but not the package containing the development files). > (and of course a bunch of other caused by these). > > How can it not even find libosso.h, for example ? Find the packages containing libosso.h with dpkg -S (use full path), and add this packgae to your build-depends, too. > Of course it compiles just fine in my scratchbox environment. The autobuilder installs only the packages you ecplicitely name as build-depends. Your envrionment has all packages available from the start. > Am I doing something wrong or not doing something I should, instead, do ? You are missing build-depends! -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: More autobuilder problems (armel only)
Hello!
> ./configure --host=arm-linux-gnueabi --build=arm-linux-gnueabi
> --prefix=/usr --mandir=\${prefix}/share/man
> --infodir=\${prefix}/share/info CFLAGS="-Wall -g -O2"
> LDFLAGS="-Wl,-z,defs" --disable-darwin --disable-xsmp
> --disable-netbeans --enable-gui=no --disable-gtktest --disable-gpm
> --disable-acl --disable-nls
>
> I did pass through some extra ones (either disable-darwin et al),
> however the --host and --build were added automatically.
>
> I'll try resubmitting and see what size the log is then :-)
I would try to drop the --host and --build parameters to the configure
script. One would have to look at the config.log the exactly see what
happens and why this results int he C compiler not working anymore. These
line are relevant for the debian packages to support cross-compiling
(directly pass the target system) but in the maemo autobuilder environment
they possibly do harm (perhaps the configure script assumes special names
for the compile, which does not exists. config.log would tell us).
My packages work without them. The configure script then tries to detect the
platform itself and was right in its guess :-)
It would however be interesting to hear from the autobuilder people how we
should cope with such debian specifica?
--
Gruß...
Tim.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo-extras repository access?
Hello! > o.k. I got past the libgpsbt-dev issue. Now libagg-dev is giving me > problems. Autobuilder fails on it. Looking at the logs, it compiles > successfully on autobuilder but the package build fails. (see fail log > below... > install -m644 ./src/platform/X11/.libs/libaggplatformX11.a \ /home/builder2/maemo-diablo-armel-extras-devel/work/agg-2.5+dfsg1/debian/li bagg-dev/usr/lib/libaggplatformX11_pic.a > install: cannot stat `./src/platform/X11/.libs/libaggplatformX11.a': > No such file or directory Hm normally for debian packages you call your configure scriptg with --prefix=/usr. Then you normally build and then install by calling make install with setting DIST to some temorary diretory below the debian diretory. From there you then build the package content. In your case you directly build package contentg from your souce directory. I dcon't know if this wrong but at least not the normal way to go. Nevertheless you either have passed the wrong path (but earlierf install calls worked) or the library you was not build. Check make log and configure call. -- Gruß... Tim. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: More autobuilder problems (armel only)
Hello! > If you wanted to look at the vim ones, I wouldn't recommend it on the > tablet. Apart from the problem I'm having, something else went wrong > with the build and the log's 28MB (it took over 12 hours) beeing away from home that was exactly what I tried. I already failed looking at the log. This seems to be a good real life test to create some new bugs :-) > I'm /fairly/ certain it's not related: an earlier build also failed, > without generating a 28MB summary. Not beeing able to look at the source I have to guess. Do you pass anything besides --prefix to the configure script. Normally you should need to pass anything besides enabling or disabling optional features. -- Gruß... Tim. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: More autobuilder problems (armel only)
Hello! > Ed/Niels/anyone, any ideas? The armel package builds perfectly well in > my own Scratchbox, just not with the auto-builder. > > Thanks in advance, I wanted to take a look at the complete build logs in the extras-caldron mailinglist archive but the chinook browser cannot show the overview page. What is that? Is this a known bug? -- Gruß... Tim. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo extras repository proposal
Hello! > This is all good, but I don't think it makes sense to do in now. > The main problem with extras for now are the maintainers' attitude. > There were a lot of discussions about extras previously on this list and > no real actions were done by community. I don't think it is fair to blame the developers without looking for reasons. I'm sure there are reasons for the current situation (some already responded to your mail). The situation needs discussion but not simple blaming. Situation is frustrating but worse could happen. > After we accomplished Misha's plan[1] several months ago[2] we had no > feedback and almost nobody used autobuilder and promoter. I can speak for others but I personally tried to find a solution between improving existing and developing new software, switching the employer (plus working overtime), moving to a new home, buying a new car and other stuff. I'm not payed for developing open source software so other things have priority. > With this attitude I don't think it's feasible to go further and develop > additional features which will not be used again. Instead we should > probably concentrate on encouraging maintainers to actually use the > tools and to give feedback. From this point of view Niels proposal is > more than enough for now. So back to the possible reasons for the situation (I cannot speak for others, so other developer please add or correct!): * Nokia did not give a long term release date but expects developer to just be prepared. I can understand why Nokia does not give long term release date (the reasons are obvious) but as a result it must ramp up such stuff far ealier (should have made advertisment and plans for strategie for diablo much earlier) to get a result in time. Perhaps annoucement was made but at least me was still suprized by some aspects. Assume that every (re)action of an open-source developer may take 2-4 weeks, even if a task of 2 hours is to be completed. * Nokia must realize that the current autobuilder and extra repository infrastructure possibly still give no real gain for me and possibly others. As long as I can add *.install files to my own repository in the downloads section having an own repository is simpler than using the autobuilder. The current infrastructure: + Is slow (autobuilder needs *much* longer than my local computer) and currently even seems to be overloaded. + There seem to be smaller bugs, making some builds fail for no reason + Needs more initial setup to be usable + Cannot handle dependencies, neither does it seem to compile packages in queueing order (so having one library and multiple depending applications I cannot "upload and forget"). + I cannot push packages for multiple OS versions on the same time via the web interface (will take a look at dput) + Does not build packages for older distributions, so I still have to compile packages for older OS version myself, having twice the effort. + Does not support other niftly stuff like lint etc... + Integration with downloads could be much better + extras is more a mess than an really atractive place to be for my packages ;-) Quality was requested but control and enforcement seems to be weak. + Suggestions for improvements will not be rejected but the reaction suggests that things will take a long time (and suggests that I can slow done pace, too, which is definitely the wrong signal ;-)). The current situation is the direct result of this and for me personally no suprise (in fact in the last big discussion I participated I even hinted that this will happen). However I don't think that keeping things the way they are or at least slowing down the development of this the totally wrong way (under given goals). This is the totally wrong signal and will kill extras repository. Instead a way to accelerate the development and invest in improvement must be found. It looks like Nokia is waiting for the community to jump in, but possibly critical mass is not yet reached for this. Or why we discuss 2010 agenda? How? If the community cannot help or does not want to help (because hacking software is cooler than improving infrastructure?) Nokia possibly must either help, extpectations must be lowered, or another strategy must be found. For me it looks like we are still no team. Another question: How could the proposed community board could help in such situation? -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Rebuild all chinook source packages on autobuilder
Hello! > I failed to mention that I found the .pc files but then didn't get the > link back to the package. > So if I'm understanding you, find the .pc file, do a dpkg -S on that > pc file, take the name of the package, add a '-dev' to the end of it The *.pc can normally be found under /usr/lib/pkgconfig, so... dpkg -S /usr/lib/pkgconfig/gtk+-2.0.pc libgtk2.0-dev: /usr/lib/pkgconfig/gtk+-2.0.pc > and put that in the Build-Depends line? I'm not near my scratchbox to > try this but I will this evening. The *.pc files are part of the content of a *-.dev package. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Rebuild all chinook source packages on autobuilder
Hallo! > So if your package is failing due to missing dependencies, how does > one map the package check to Build-Depends? I'm sure this is a basic > question, I've googled but not found a definitive answer. The links > referenced in this thread are very general. > > For example > PKG_CHECK_MODULES(GTK, gtk+-2.0) needs libgtk2.0-dev > PKG_CHECK_MODULES(CONIC, conic) needs libconic0-dev > > What establishes the mapping? > > Specifically, I'm missing the Build-Depends for hildon-help. I do not understand the question completely but perhaps my answer helps you anyway. If your application configure script requires some external dependency like in your example gtk+-2.0, this dependency is fullfill fromt eh view of your application by finding the corresponding *.pc file as defined by pkg-config. This *.pc file is normally part of some *-dev package which in turn means that your configure scripts expects that this *-dev package is available (and properly installed and configured). So to make that package viewable for configure script at build time you must mention the exact package that own and contains this *.pc file (AFAIK dpkg- S is your friend here) in your build-dependencies because the build dependencies names the packages that should be installed before your package is build. The autobuilder starts with a clean envrionment and will only install the packages you name. The *.pc file in turn contains the information what additinal include paths and libraries you need to build against the given package. It is a ASCII file. Just take a look. PKG_CHECK_MODULES is of course only one way to detect if a library is available. There are others - however the all expect the corresponding *-dev package to be installed. Does this help you? Any aditional questions? -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo Application Package help
Hello! > But I am not able to add these images to the deb package and because of > that when i am installing the > application on device , the images are not appearing. See http://illumination.svn.sourceforge.net/viewvc/illumination/trunk/PushIt/ and especially http://illumination.svn.sourceforge.net/viewvc/illumination/trunk/PushIt/Makefile.am?revision=1577&view=markup how to install images into the package using autoconf tools. In this case the make file itself gets the information that these images are part of the packaging, so that a "make install" in the debian rules file (http://illumination.svn.sourceforge.net/viewvc/illumination/trunk/PushIt/packaging/maemo/rules?revision=1595&view=markup) will install a the right place. Using something like PushIt_CXXFLAGS=-I. $(ILLUMINATION_CFLAGS) -DAPP_DATADIR=\"$(pkgdatadir)\" in your Makefile.am you can pass the top level pkg data directory to the application (see http://illumination.svn.sourceforge.net/viewvc/illumination/trunk/PushIt/src/Makefile.am?revision=1577&view=markup). Hope this helps. The debian rules files also shows how to install application icons. For this also take a look at the postinst file: http://illumination.svn.sourceforge.net/viewvc/illumination/trunk/PushIt/packaging/maemo/pushit.postinst?revision=1595&view=markup -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gstreamer on n800 with OS2008: wrong resolution?
Hello! > /home/user # gst-launch v4l2src ! xvimagesink > Setting pipeline to PAUSED ... > Pipeline is live and does not need PREROLL ... > ERROR: from element /pipeline0/v4l2src0: Device '/dev/video0' cannot capture > at 800x480 > Additional debug info: > v4l2src_calls.c(929): gst_v4l2src_set_capture (): /pipeline0/v4l2src0: > Tried to capture at 800x480, but device returned size 640x480 > ERROR: pipeline doesn't want to preroll. > Setting pipeline to PAUSED ... > Setting pipeline to READY ... > Setting pipeline to NULL ... > FREEING pipeline ... > How can I fix the resolution? See: http://maemo.org/development/documentation/how-tos/4-x/how_to_use_camera_api .html You would have to pass corresponding capability information regarding the requested capture size to gst-launch -- Gruß... Tim. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: new developer, dpkg-reconfigure missing?
Hello! > I haven't found any help googling around, other than that > dpkg-reconfigure looks like it should definitely be included in the > scratchbox installation. I had similar effect after installing OS 2006 and 2008 Beta SDKs over my OS 2007 SDK in the same scratchbox instance. Dropping the SDK installations and reinstalling of the SDK made the problem disapear. A simpler fix may have been possible but I had no indeep scratchbox knowledge for this. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
Hello! >> 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.) That was my question in another thread. How do I manage my garage project(s), if I have more than one but all closed bound together. I think we should allow to have multiple packages for the same project (thing of localization packages, too) and belonging to the same garage page. I also would find it useful to make tickets int he bug tracking system of that project page if building fails (error text then of course should clearly identify the package). This way we have some feedback if the problems was solved (ticket closed). This way we could also see if the maintainer has given up getting the package to run. We could also resume rebuild of the package after ticket was closed saving build resources. 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? -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
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. 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 ;-) -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
Hello! > libraries until the APIs are more stable. This means that there are cases > where a dependency is updated where all the dependent packages need to be > rebuilt. > > Of course, this does not only apply in cases where library versioning is not > in use. Even in cases where libraries are correctly versioned there may be > some benefit (e.g. a performance benefit) in rebuilding a dependent > application. I'm also the developer of an "alpha-version" library. I would suggest in this case to add for example the exact date as package version (e.g. 0.1.20071110) and make all dependent packages dependent on exactly this version. I know that all dependent packages then need an upload (with an incremented package revision at least) with this new dependency to get build again, but IMHO there is no way around. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
Hello! > Levi Bard wrote: >>> [1] Is OS2007 support still useful? There are really only two platforms: OS >>> 2006 for 770 owners, and OS 2008 for N800/N810 owners. Maintaining OS >>> 2007 >>> support could be a pain for application authors. >> I would say that the two relevant platforms are OS2007 for 770 owners >> and OS2008 for N8[01]0 owners. I definitely have users of my applications that still have an 770 running OS 2006 (however I cannot give any percentage). -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
Hello! I have collected (and reformulated a little bit) all suggestions up to now in the Wiki at: https://maemo.org/community/wiki/extrasrepositoryprocessdefinition/ I have divided the suggestions in to three groups: autobuilder, autotester and autostager (note that even with only one or two repositories the autostager can decide about "in" or "out") to keep the overview. Please check the page and assure that your suggestions are collected and correctly formulated (everybody can change!). If we collect more suggestions a separate page may be appropriate. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hello!
> different. And the main problem with 'extras' is that there're not so
> many applications in it.
> I believe it's because of a simple challenge for developers: 'extras' is
> expected to have good quality software ("good" is still to be defined
> :)). I saw quite a few comments (here, ITT, elsewhere) like "well, I'm
> not 100% sure that my software is good enough to be put in 'extras', so
> I'd rather make my own repo". And as soon as the developer makes her
> first repo for offering some alpha/beta software, it's gonna be
> comparatively easy for her to _also_ create a repository next to the
> first one where the stable/good stuff is made available. As result
> 'extras' is underused.
Correct. The initial aim defined by Quim Gil was:
I would like to have for packages in extras instead in far away
repositories. I want it to get easier into extras but I do not want to
sacrifice quality (and quality is the point that makes it difficult).
I own such repository. I'm unsure if my applications are "good enough".
Making the repository however is not the effort for m (making the
repository was easier). My problem is maintaining builds for three OS
versions (Would it be wise to drop OS 2007 after the release of OS 2008.
Can I assume that everybody will flash its device?). It seems like not
all people are for example running OS 2007 HE on their Nokia 770). My
problem is maintaining the downloads.maemo.org packages. My problem is
missing testers.
> The point of this plan is to explicitely make available a central place
> where there's no such a vague restriction as "it must be good", so
> developers instead of learning various tools (dpkg-scanpackages,
> apt-ftparchive, reprepro, etc) would just learn one -- dput.
>
> 'extras' repository is coming pre-configured in Chinook and, since it's
> disabled by default, the "normal" user would need to do something to
> enable it. 'extras-devel' is _not_ pre-configured, so only brave souls
> would add it to their catalogue list.
Ed argumentation (I need a repository for testing and staging together
with other people/projects) is valid and I acknowledge it. However his
motivation is different. As such I doubt that the first 2 steps will get
you more applications into extras, you just make it easier for people
that already have extras applications and want to increase their pace.
This is a valid reason.
> I think _some_ of the problems will be solved (see above). Advantages?
> I do not know. So far alsmost nobody really followed up with 'yes,
> that'd be great, [let's] do it!' message :)
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.
I must assume they we by far are not talking about the real problems,we
have lost the audience because of the long discussion, or that there
are no real problems (form the view of the community) :-/ Scanning some
#mameo logs I have seen that some people find a staging approach too
complex. Me too, but how do we solve the quality problem instead?
Perhaps it is time to make a poll :-)
> Who is the group? I'd say at the beginning we should forget about
> groups :) and just make it working on 'I own this package, I move it'
> basis.
That would be OK for me :-) I think I'm able to judge which of my
applications are good enough and which are not. But this way we cannot
assure the quality aims that were defined by Nokia.
> Well, my original proposal was to make it better only after we reach a
> substantial checkpoint :)
As said before: If the discussion does not proceed with better
aproaches, just do Steps 1 and 2 instead of doing nothing.
--
Gruß...
Tim
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hello! > I'd like to share a simple 5-step plan :) It seems that the discussion > again somehow stopped. The first steps of the plan seem to be quite > practical, so hopefully we can start implementing something. And I'd > strongly suggest we proceed with step 5 only after having implemented > steps 1-4 :) > Step 1: Create the repository itself > Step 2: Create "promotion" interface > Step 3: Add building facility > Step 4: Making "promotion" interface a bit more sophisticated > Step 5: Make it better? :) Wait a minute! Please rethink why we initially wanted a different behavior for the extras repository. By initiating Step 1 and 2 immediately will we have solved any of the problems we initially detected? Is there any advantage to the current extras repository and will give it some momentum to "the plan"? I'm not against acting with initial steps instead of discussing things to the very end, but I think this suggestion is a too quick one. The solution points to problems which were already be detected and not clearly solved (especially the discussion about "who is the group" and "how will they decide"). It also is easy to find people to "decide", but we definitely need people who are willing to "improve the infrastructure" and do the hard work. If we do not get them now, your idea might die a step 3, too :-/ I think there was some agreement on staging repositories similar to debian together with some autobuilder mechanism. I think this is a basis that would be better for start. Isn't there a chance to get such stuff running in short time? We do have a few weeks time to set such stuff up. We do not need a solution tomorrow. OR is there a down striped solution (without staging) that would still give us some benefit? What for example if we use http://mud-builder.garage.maemo.org/index.php instead? The author has planed to use it for rebuilding upstream packages but I think using it would give use more benefit than just switch to totally manually mode (which we already have). It has not much but at least more infrastructure. Can the author of mud please give his opinion on my silly idea :-)? Or isn't there somebody who is able to set up real debian autobuilding? I think that as soon we have autobuilding, evaluating rating and bug systems for staging should be possible. The advantage is, that the information is already there. We have the rating under downloads and we could use the garage bug tracking for each application (which would mean that each application must have at least a garage project page). Please: Any volunteers (Quim can you spend some karma for this ;-)?)? And please don't misunderstand we. I'm not saying "don't do this!", it just a "good idea, but couldn't we do better with similar efforts?". And if we don't get some autobuilding or rating stuff set up now I'm definitely in favor of your solution. Another question: Sooner or later we need some information and/or active support from the infrastructure. For example it might be helpful to get some CSV reports (or similar) from downloads or statistics from the bug tracking system (bugs.maemo.org or garage). What can we expect? Do you have a "one sentence formula" about the grade of help Nokia can give in a given time frame? -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hello! >> * We must find some clever way to get a response from the user >> since we cannot trust "the masses" (our masses are not of >> equal size then that of debian). >> * For example: What about the program manager on the device >> periodically >> requests a rating from you for newly installed applications. >> There will of course be a way to switch it off, and the the >> notification must not violently jump into the middle of the >> screen swinging its broadsword, disturbing my circles. > > We might discuss about this feature in the Application Manager. However, > if you find this idea useful it would be faster and probably better to > start with an installable 3rd party application covering this > functionality and targeted to maemo power users. I checked again. It seems like libcurl can do the "fake HTTP requests to at ratings to the application catalog". I already have code for browsing package lists. So I should be able to: * Show list of packages (in user-section) that were not rated or where there was a rating for an earlier version (can I re-rate applications if the version changed? Should be possible IMHO => Karma!?). * Request rating (0-5 stars plus free form text). * Initiate upload of rating(s) using curl and fake HTTP form POSTs. But: * There will be no periodic notifications because that would mean to always run in the background... or is there a way to do power-safe-aware cron jobs!? * User still has to have an account and must type in password. * I possibly has to guess the downloads.maemo.org application name from the package name. Here we should definitely try to define a header in the deb file! I also would like to have a bug tracking functionality as part of the applications, since I have a few users that have problems with the package installation. I could let the user choose the package and then collect information about package version, version of dependencies, device model and OS version. I could even look for a .desktop file, start the binary and collect console output. And if the rating fake works one could even make a bugzilla ticket from it... However in this case we likely needs some help from deb headers, too. => I'll do it! Give me some time... -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Question regarding garage project pages
Hello! > According to Tim Teulings <[EMAIL PROTECTED]>: >> The question is, how should I structure this in garage? Should I again >> request one project and hosts all applications there (which makes things >> easier for me but might have negative consequences for my karma :-), > Quim, this is why karma systems are a bad idea. I'm sure that Tim was > joking, but as soon as people start even thinking about how their Of course I was joking. I was more interested in a recommendation how I should manage my currently over 10 packages. I think both solution have some deep organizational consequence that I alone cannot yet overview. Also it is a good question to stimulate more discussion about the future of the extra repository and the corresponding infrastructure. > actions affect their karma, rather than doing what makes sense, the > karma system has negatively affected the project and community. We all sound a little bit "karma crazy". Even Nokia people sound like they are not sure if they should like their own idea ;-) But I think this is only temporary until everybody understands what is happening, how it works and what it is good for and that good karma is no automatism for being honored, helpful and well known. The reaction was not surprising. Both sides should keep relaxed and have trust. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Question regarding garage project pages
Hello! I would like to move the maemo specific parts of my currently sourceforge hosted projects closer to garage. The source (which is not maemo specific) is currently hosted at sourceforge and the repository is hosted on my private web page. I have a number of packages for smaller applications which all are based on a common GUI framework. At sourceforge I host all applications in the projects space of the GUI framework project. New releases are currently always of the "all packages updated" kind since the GUI framework is still in development, chances in the GUI library and one application normally requires updates of all packages. The question is, how should I structure this in garage? Should I again request one project and hosts all applications there (which makes things easier for me but might have negative consequences for my karma :-), for other users and for my compability with the discussed infrastructure planes for the extra repository) or should I request a individual project for the library and one for each application, which would generate some stress for me on every release? I can see that it is possible to link to homepages outside of garage. Is this also possible for subversion (link to www.sf.net..., since I will not move or duplicate the source to the garage subversion repository)? -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hello! > Speaking about decisions. Someone wants to summarize the discussion in a I did that: http://maemo.org/community/wiki/extrasrepositoryprocessdefinition > wiki page and call for review? I'd suggest separating the principles > from the implementations, since we seem to agree already in the first > ones. Stamping a deal on the principles should make easier the agreement > on the implementations. I tried to go through the mails in this thread and collect all relevant comments hints. If somebody misses his ideas, simply add them. Please comment, discuss, tear in in two, edit, delete and enhance. At the same time write a comment to this thread :-) Please try to keep your changes withing the existing structure or improve it ;-) -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hello! >> * We must find some clever way to get a response from the user >> since we cannot trust "the masses" (our masses are not of >> equal size then that of debian). >> * For example: What about the program manager on the device >> periodically >> requests a rating from you for newly installed applications. >> There will of course be a way to switch it off, and the the >> notification must not violently jump into the middle of the >> screen swinging its broadsword, disturbing my circles. > > We might discuss about this feature in the Application Manager. However, > if you find this idea useful it would be faster and probably better to start > with an installable 3rd party application covering this functionality and > targeted to maemo power users. I checked this. And in fact using libapt-pkg (no header files in chinnok beta?) it is easy to get the list of installed packages in user sections. Using some application internal configuration file it should be possible to locally track rated and unrated packages (and even packages where one has rated an earlier version). One questions however persists: If I now have a local configuration file containing new, undelivered ratings, how do I get them into the application catalog? Must I really track available/unavailable network connection, popup a dialog (or not) and then fake HTML package changes by sending successive HTML/SSL requests to the application catalog? Isn't/shouldn't there be a simpler solution? I'm willing to develop a GUI for the rating collection task but I happily delegate the upload to somebody else that has knowledge in writing such system service. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Initial version of my packages for chinnok...
Hello! I just put initial version of my packages build under OS 2008 in my repository (see http://www.anderenen.de/anderenende/maemo.html). I assume that the application are still functioning (at least they do with the beta SDK release) but expect minor problems with the theming. If any of the few souls out there already owning a N810 would like to risk an installation don't hesitate. Any feedback is welcome. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hello! > Depends. The "guide" (aka the Debian Policy Document, aka "policy") > distinguishes between "musts" and "shoulds". Violations of "musts" are > considered Release Critical bugs, violations of "shoulds" are non-RC > bugs. Specific exceptions for specific packages have been made, when > justified. >> In the case we do not need a guide first, but the process will come >> first and then the guide will develop. > Arg. No. The guide is critical. That doesn't mean the first release has > to be perfect, and that it will not evolve, but you need guidelines. > There's a lot of stuff in Debian policy that isn't directly related to > good or bad, but simply choices. Consistency is an extremely valuable > quality, and there's simply no way to encourage it (must less enforce > it) without documented policy. I was possibly not that clear in my formulations. I think that we may still share the same opinion. IMHO we are talking about two different aspects of such a "guide". The first one - the one that I think you mean (and that I think is important and must be agreed on to initiate the process) - is the guide that defines the process. Of course an important part of the process is for example packaging. You a right in that we can copy most of such guides from debian. However it is likely that we have to modify this. For example we may need some additional headers for the in parallel discussed bug tracking client application. So here we agree :-) If you look at the said guide Quim mentioned however this guide does not define the process and the framing rules for the extra repository and its uses, but is is a (in future :-)) detailed list of test cases to determinate the quality of an application (of course Quim might have planed something different, but this is my interpolation into thefuture). Part of it is packaging (which overlaps with the rules) but some part might develop in a check list for a tester. Such checklist is not required now, because the process does hopefully handle quality without explicit quality assurance by a trusted person. We currently would require only general requirements (which could be part of the guide) but again the process will find its own (possibly surprising) requirements - the requirements of the people that install and vote. For example we may find out,that fine power management is not important to (wild guess) 50% of the people. So who are we to forbid battery killing applications their march into the repository (hmm, however the other 50% may like to know...). > And while there's quite a lot in Debian Policy that may not apply, or > needs to be reconsidered for the tablet environment, there's a lot > that could be adopted as is. It's certainly better than starting from > scratch. And gratuitous differences should be avoided like the plague. Totally agree. For example the staging stuff and the packaging system seem to have general agreement by nearly all participants in this discussion. > You'll never ensure this. What you can hope is that packages that move > from whatever-we-call-unstable to whatever-we-call-testing have had at That process is completely OK and I never spoke against that. However I think we must tweak it a little bit for our purposes and framing conditions: * We have a much smaller user base. So we must make feedback as easy as possible. * We have mostly GUI applications which may make things easier in some situations. * We have that nice application catalog :-) * Or desktop is much simpler and thus we can better integrate our process into the desktop. > I also want to point out the classic "the perfect is enemy of the > good enough". The processes and documents can, and should, evolve as [...] Security, quality, central approach - all part oft my initial claims :-) -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hello! > Alright, what about leaving the role of this document in a checkbox developers > check in order to get upload rights to extras, à la terms & > conditions. Something like "I'm aware of the maemo Quality Awareness criteria and > I have tested my applications against them before uploading them to > extras". Hmm, you never would get my applications ;-) I'm pretty sure that I won't fulfill all the requirements. For example being good at battery time is a tricky thing to test (it possibly that my applications do not stop cursor blink when the device tries to sleep (I'm not using Gtk)). and I'm sure that for my application that isn't really a problem. So possibly there should be more than one checkbox so that I can say: * Stable * Installs well * Deinstalls without problems and does not leave anything on the device. * ...but possibly does not handle power management that well. We would have some kind of (hopefully small) checklist that precisely tells the potential application user what he can expect and what risks he will take. But thinks are getting possibly too complex in that direction. I have visions of a number of strange symbols behind each application name in the application catalog (like a battery for power management aware applications and similar) and some users might get information overflow and are in the end not able to make the right decision. Btw., (de)installation checking can be automatized (much better than testing it manually). Somebody already has some script for that. That should be definitely part of the solution! So that part fo the checlist could already be dropped. Does that really lead us in the right direction? What realm harm could be avoided by that checkbox? I think that checkbox can only avoid installation harm that possibly can also be avoided be automatic testing. If an app kills a device (and the developer knows that) that there is possibly already some criminal minimal mind behind - and then the checkbox would not help either. > Of course developers might check the box after having gone through the 100%, > 50% or 0% of cases and his software might or might not contain major bugs, > but at least nobody can say - 'sorry guys, I didn't know my app could brick the > device'. OK, but to what benefit? To sue the developer ;-)? What is the real effect of such a checkbox (see above)? >> * A packages does not get into the stable repository if its >> bugs are "over the limit" (and debian has a precise definition >> for "limit" :-)). > > Any requirement about where these bugs should be filed? The minimum > requirement would be a public bug tracking system and responsiveness from the > developers. I already mentioned a central bug tracking system for the whole system or at least for all applications in the bug tracking system. So that would be OK for me. >> * A packages does not get into the stable extras repository if >> there are not at least X successful installation and >> "behavior" reports. >> * A package needs some average ranking to enter the stable repository. > > http://maemo.org/downloads can serve well this purpose. That I also already proposed. Agreed, too. [...] >> * For example: What about the program manager on the device >> periodically >> requests a rating from you for newly installed applications. [...] > We might discuss about this feature in the Application Manager. However, > if you find this idea useful it would be faster and probably better to > start with an installable 3rd party application covering this > functionality and targeted to maemo power users. I would love to implement such stuff (and I'm sure I could, if there are the necessary interfaces) :-)). But since I have my own GUI library (so the result would not be a GTK application) and no knowledge of apt I would step aside for somebody else ;-) I also think this would require some nice interface in the applications manager, else somebody has to fiddle with faking SSL HTTP requests :-/ >> * Also it might be very effective to collect and submit >> regular crash reports from the device to the application >> catalog (of course delivery must again be optional and not the >> microsoft way). > > Good point. See Gnome (and Windows Vista :-/). >> * Also we need a very easy way to get bug reports (and feature >> requests) directly from the device into the bug tracking system. > > It is clear the convenience of having an automated way to send crash reports > with traces, but what else would be needed other than that? Do you > mean an option inside the application saving you the effort to find the > right bugtracker/product/component? I would not propose in-application solutions - simply because not all people use Gtk for development (especially me;-)). Collecting crashes is technically solved by the application starter process (wait for SIGCHLD). It would make sense to integrate (or at least base it on information from) this i
Re: Repositories mess: conclusions and actions
Hello! >> - Nokia: We want to centralize the development to just make things >>easier", "simpler" and add service - without compromising the open >>source idea. (Simplicity, centric) > Centralization doesn't compete with 'the open source idea'. We are I did meant that (it was meant exactly they way you define it, too). Centralisation can mean "control" (upto totalitraianism). In the context Nokia IMHO explicitly stated that they want control for good and want to take control together with "the community". > proposing it not because we are Nokia but because we are running maemo > on top of GNU/Linux and .deb packages. Just look at how your preferred > open source software distribution is organized, it is almost a paradox > that most if not all of them are in fact more centralized than maemo. Right. It sound easier to take part at the "extras" process than to get a debian developer ;-) For small communities it is important to be open. >> - Nokia: We want to multiply by delegating task to the community >>(Scalability) > > Delegating is not accurate enough. We want to empower the community to > push and promote the software they think is good enough for that. OK. >> * Definition of the meaning quality in a community that consists of >> Nokia and the open source community. > > The Quality Awareness document is open to improvements and > contributions. We don't want/need to have different docs to define & > measure quality, so whatever idea you have please check it against the > current doc and suggest improvements to it. The question is not the quality of the "Quality awareness document" which likely could be improved. The question is, if such a document is the right way to control quality? How would we guarantee the quality defined by this document? This can only be done by manual test (at least definitely if we would further improve the document ;-)). The test have to be done by the developer first. However since you cannot (always) trust the developer, somebody has to test the application again. So what we then would need, is a in-queue with new packages and every package has to be manually testes. This would assure quality on a very high level, but likely would not scale (and possibly would not work with a small community). Note that debian FTP master as far as I know only check license stuff and similar - they do not check the application itself (and they are sometimes still slow (for whatever reasons)). This kind of quality assurance is the classic way for companies. I doubt this is the right way to go. The Linux community distributions handle quality differently. They use same small initial checks and then a staged repository. Debian still has a policy and style guides and similar and tries to do automatic checks that guarantee compliance with these guides. However most the actual "crashes" bugs are notices after the software initially entered the repository. In this case a "guide" is still good (and you always get your bugs fixes if it violates the guide ;-)) but quality get a much more diffuse meaning. I'm sure that debian has a number of applications, that don't fulfill all the requirement in the guide. In the case we do not need a guide first, but the process will come first and then the guide will develop. The problem is: How to assure that still no important bug (that for example kills my device) gets through. In this case I would still suggest using the three holy kings (bug tracking, staged repository, application catalog) but at this point would not concentrate on the holy guide but on the holy process. For a small community with with high quality requirements (and debian has also high requirements for their community is bigger, so they have a very high trust that no bug get trough the process) I would still suggest: * A packages does not get into the stable repository if its bugs are "over the limit" (and debian has a precise definition for "limit" :-)). * A packages does not get into the stable extras repository if there are not at least X successful installation and "behavior" reports. * A package needs some average ranking to enter the stable repository. * We must find some clever way to get a response from the user since we cannot trust "the masses" (our masses are not of equal size then that of debian). * For example: What about the program manager on the device periodically requests a rating from you for newly installed applications. There will of course be a way to switch it off, and the the notification must not violently jump into the middle of the screen swinging its broadsword, disturbing my circles. * Also it might be very effective to collect and submit regular crash reports from the device to the application catalog (of course delivery must again be optional and not the microsoft way). * Also we need a very easy way to get bug reports (and feature requests) directly from the device into the bug tracking syst
Re: Repositories mess: conclusions and actions
Hello! >>> * Since Nokia holds most of the infrastructure I fear Nokia has the >>> burden to supply the technical infrastructure while the community will >>> support the daily work, the rating and the quality assurance. > >> Fear? If this doesn't sound like a fair exchange then please suggest >> fair proposals. > Er, I think you misunderstood him: he used that word (fear) projecting it > to Nokia, not to himself... Something like "I fear it will be Nokia to > have the heavy burden of maintaining the technical infrastracture; instead > the community will...". > > Does it sounds good? > Or maybe it's me misunderstanding him :) Correct. There was no criticism (especially towards Nokia) in my words. It it just that for a join aproach between Nokia and "the community" one would expect that both parties would do nearly the same amount of work. Regarding infrastructure this will likely not work. Since Nokia will (likely) host the infrastructure they have to do most of the work. So I said: Sorry Nokia, it seems like you will have to do more work than we. On the other hand it is likely that the every-day job may require more efforts for "the community". If both sides can live with that, thats OK. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hello! IMHO this discussion is important, but needs some kick to start discussing real concrete solutions in more detail and to agree on suggested behavior. I would suggest to continue discussing but in the end of each of you mails define short statements, that summarize your idea and ideally are a "patch" to this or a similar list (especially my conclusion could be more concrete and shorter :-)) and especially agree or disagree explicitly on points already suggested to get a common opinion. So I try to summarize and extract the key points already mentioned. Problem === - Nokia: There are many applications that would increase the wealth of our product, but me must guaranty + Quality (Quality) + Ease of use (Simplicity) - Nokia: We want to centralize the development to just make things easier", "simpler" and add service - without compromising the open source idea. (Simplicity, centric) - Nokia: We want to multiply by delegating task to the community (Scalability) - Nokia: We must keep security in mind - nobody must be able to inject bad packages etc... (Security, Control) - Nokia: We want to attract new developers and give them a guided testing bed (Iterative) - User: There are a huge number of applications. Most of the applications would promote the devices and the platform, but it is difficult to + find the application (Locate) + judge, if the application has "quality" (Quality) - Developer: Developers have problems to promote their software (Promote) - Developer: It is difficult to assure that the application is installing and running well on all devices (Quality assurance) - Developer: There are multiple platforms and I need to do building for them all manually (Build management). - Developer: Not every developer is similar. The process must support + Garage + External projects but local packaging + External projects (Flexible) Claims == This results in solving problems that can be described by the following key points (I admit that these are very common problems when working in the software development process ;-)): We need a process that... - Defines Quality - Assures Quality - Is simple - Is somewhat centric - Is scalable - Assures security and control over the process - Is iterative for developers - Helps user finding a application - Helps promoting software - Eases building packages - Must be flexible regarding package sources Comments So some comments on some of the key topics. Quality: Quim quoted http://maemo.org/development/documentation/how-tos/4-x/quality_awareness.html but this is only a start. But Quim itself admits that there already software that is promoted while not fulfilling all criteria (and this is IMHO the right thing). So we need a better definition on quality like: * Number of users installed must be significant. * Number of bugs (=> Debian) * Rating (as a soft criteria that signals requirement for further investigation). (=> Application Catalog) There is also the question about who decides the quality? The process (=> Debian)? The user itself based on some numbers? Nokia? To assure quality the process must react very quickly (more quickly like in Debian staging repositories). Simple: Simple for me means that it must be automatic. Things like auto building, evaluation of open tickets and application catalog integration are IMHO a must. Centric: * Means that there is one official repository (which may be split into stable, testing..), one application catalog, one ticketing system. There is no way around this if we want to guarantee security and quality at the same time. Scalable: => Automation and having a => group of people. At least part of the team should by non-Nokia "people". Security and control: So we need signing, secure process injection protocols and a clearly defined process. I thing Debian has a number of additional mechanism that could detect problems with Copyright and similar by scanning packages and differences between package versions etc... Iterative: We need staging repositories and a rating system that has more states than "good". Finding Applications: We have the application catalog which might need improvement but I see no other solution. Promotion: We could automatically generate high scores from the download numbers from the catalog and also from the rating. Promotion should be part of the catalog (and the home page). There is already something like that there but could of course bee improved. Eases building/Flexible: Tools, examples and Autobuilder/autoinstaller. fetching external repositories is IMHO no go, because of the security reasons mentioned by Nokia. Having an external project page myself, I see the problems but also see the problems supporting me. IMHO garage should be able to delegate parts of a project (web page, source repository) to external (trusted) resources. Building however cannot be externalized, so I still have
Re: N810 maemo device program open for submissions
Hello! >> * How can I better promote my application in this case? Can I make a >> garage project page for my application? Would this make sense? > > We need to help developers promoting their applications in any case, [...] > news or blog about it... Having a project in Garage helps, yes. Hmm, as asked before: In my case (and possibly others) I also have a sourceforge project page. So while I can make a separate garage projects for each of my projects it is likely that I would not use much of the infrastructure. Especially I would not use the subversion repository, since all my code is already placed at sourceforge. And I likely would link to my sourceforge homepage for more information and else would duplicate information from the sf homepage. However it still looks like I would profit from this so: if this is OK for you, it is OK for me ;-) It would be nice if external hosting sites would be integrated/supported better, but I would need to play a little bit more with garage to make concrete suggestions. >> The Application Catalog still seems to be horribly broken. > I wouldn't be so tough bu in any case let's evaluate OK. That was to drastic, but in fact I plan to build initial version of my packages for OS2008 within the next two weeks (just need some final finishing touch for one package) and of course I will update the information in the Application Catalog. However it seems that anybody that looks for already existing applications for his 810 currently will not find them (if this package is also available for OS 2007 or 2006). That is at least more than "not nice" ;-) > http://downloads.maemo.org once we have implemented the round of > improvements to be released one of these days. See > https://garage.maemo.org/tracker/index.php?func=detail&aid=948&group_id=106&atid=460 Sounds good :-) -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N810 maemo device program open for submissions
Hello! > * Contributors apply themselves through their maemo profiles. No > invitation is needed. Please don't send us extra emails, they > won't help you. Some questions: * When will my profile (and the related links) be evaluated? A Short time before the release or a short time after applying? I'm asking because: Is it wise to apply now or better shortly before the deadline? It sounds like the profile will improve over time. And of course I will try to promote my skills using the linked pages. So applying later may be better!? (I would suggest a "make your self attractive" deadline ;-) Please understand: I don't want to ceat but I want to make sure there is the information you are looking for. * Is the sourceforge link in the profile meant to be a link to my personal source "users" page or to a sf web page for my project(s)? I'm asking because the users page does not tell that much (and it looks like I can only publish my skills if I enter a resume :-/). * I'm currently hosting by applications using sourceforge (because they are not maemo only, just maemo "optimized", I use sf much longer than maemo exists, etc...), having a repository on my homepage. My application only occur in the Application Catalog. So my fear is, that people "don't see" me (see above ;-)). because I'm neither using garage for my developments nor do I see a link from my profile to my projects (which should be the case). This is a problem that bothers my for a while... * How can I better promote my application in this case? Can I make a garage project page for my application? Would this make sense? I would also suggest And something completely unrelated: The Application Catalog still seems to be horribly broken. Example: Go to the main page, sue the standard settings (2007, Any licence, Any status) and search for EightyOne => No hit. No go in the "Games" category, step to page 2 and there it is. Since I read multiple times and the catalog was broken and was fixed after and because this bug seem to have last now for quite a while I always assume that somehow this is not a bug (and f it is a bug, I have an idea what the problem is (looks like searching for 2007 does not match 2006+2007 support!?)). But now it looks like it is time for a ticket/discussion anyway. So: Is this by design (and if it is: does that make sense?)? -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Running GUI applications as root
Hello! > Have you tried using the -X switch on the ssh command? > ssh -X [EMAIL PROTECTED] The dropbear client does not have -X (the fact that DISPLAY is set after ssh [EMAIL PROTECTED] suggested to me that it might use -X always?). However since I cannot start ooso_sketch or ossoemail after logging in as root, too, suggests that -X might not be implicitely used and that my client might crash because it cannot connect to X11 (and run-standalone.sh as root does re-create the necessary environment...). Should install openssh client instead ;-) Hmm, now what about using sudo, which crashes my client, too. Does this suggest that the environment is broken for X11 applications, too, and that I have to use run-standalone.sh as part of the sudo call, too (instead sudo /usr/bin/WifiInfo I should do sudo run-standalone.sh /usr/bin/WifiInfo - but wasn't there the rule, that I cannot call scripts in this case because of security reasons?)? (Nevertheless I have to find the bug, that makes my applications crashing if initialization fails...:-/ ) -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Running GUI applications as root
Hello! [changed subject to a better one for this special topic, that does not have anything in special to do with the wlan API] > If anyone has better way to do that, I'm all ears. You can use a chmod +s on your binary in request after you did a make install to your temporary packaging directory in your debian packaging rules file. Using dh_fixperms -X the debian packaging mechnaism set the owner and group to root but does not remove the s-bit. The resulting installed file thus will have the sticky bit set. The problem however is, that this will not work for Gtk programs (and I'm not a gtk program, I just initialize it and create some widgets to read out the theming information) since gtk programs will not run with root rights. The is a assertion that will abort the application. So I switch to using sudo and enhance sudoers in postinst and prerm. This works, too. But is is possible that I should use run-standalone.sh to start my application? If I start it without it as root (via ssh [EMAIL PROTECTED]) it crashes somewhere in the initalisation code (I have to find out the exact place), if I start it with run-standalone.sh it works like a charm. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: dbus api for wlancond
Hello! > You can use sudo to gain root privileges on N800. I'm speaking of an potential enhancement for a GUI program, namely WifiInfo, wich you also can find in it in the application catalog. so doing a sudo is not what I would like the user to do :-) So, I don need to set the S-Bit? How? -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: dbus api for wlancond
Hello! > But it wouldn't be too hard write one. There's only one request and > reply IIRC. And osso-wlan sources are available, so you don't have to > guess anything: I now have some C++ code to poll the list of access points similar to the way ooso-wlan does. On my desktop PC it seems however that I need root rights to execute the underlying ioctl. Is this true for the 770/800, too? Do I thus need S-Bit for my application (and how do I do this in my debian package?) or is there another way to gain the necessary rights? And yes, I do not want to do the DBus call but implement the code my self...:-) -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: WIFI card
Hello! > Are there someone that did a simple application on > scratchbox to read all the information on wifi card on > the n800? And could he help me to do that? What are > the necessary steps before programming? What do you exactly want? Some more information pollable from the wireless support as part of the kernel. There is WifiInfo by me (www.anderenen.de/anderenende/maemo.html), that shows some more information than on-board tools and that could be extended to show even more, if someone points me to the necessary wireless extension code snipets. If you ant something else, you have to describe it in more detail. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Detecting N800 camera position
Hello! > you could also check: > > /sys/devices/platform/gpio-switch/cam_act/ > /sys/devices/platform/gpio-switch/cam_turn/ I'm really lost in detecting and changing camer position. My application uses gstreamer but is not a GTK application and thus not actively using the gtk, gnome, osso,hildon infrastruture. Using gconfv4l2src works in that I get an image but the video image does not automatically flip horizontally. As a next step I tried to add a notifier for the gconf configuration value. But this does not work. The notifier callback is never called. Perhaps because I do not use a gtk main event loop. As a next try I tried to use gconf directly to poll the state. But this does not work either. After that I checked the /sys/-values and they change. So now I will regulary poll this values as "I don#t like it but it works" solution. However how to I flip the video manually using gstreamer? P.S.: And yes, image/video flipping does work in principle as tested with the video conferencing tool. P.P.S.: If I got this working I will release a small, simple GUI driven camera application... -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Does camera in N800 support X11 Xv extension?
Hallo! Subject says it all: Does the camera in the N800 support the X11 Xv extension, that mean can I use this extension for displaying images of the camera or must I use v4l V2 (what about the V1 interface) or gstreamer? -- Gruß... Tim. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] apt-get 'could not resolve hostname' again
See my othe rthread, where I asked the same question. The answer by Andreas Oberritter was: "I encountered the same error. Scratchbox seems to copy nsswitch.conf from /etc/nsswitch.conf. See below for my changes on my Ubuntu Feisty setup which solved the problem." -- /etc/nsswitch.conf 2007-01-11 22:01:14.0 +0100 +++ /scratchbox/etc/nsswitch.conf 2007-01-25 12:20:06.0 +0100 @@ -8,7 +8,7 @@ group: compat shadow: compat -hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 +hosts: files dns networks: files protocols: db files -- Gruß... Tim. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] [maemo-announce] New Scratchbox installer for maemo 3.0 'bora' now available
Hello! > I encountered the same error. Scratchbox seems to copy nsswitch.conf > from /etc/nsswitch.conf. See below for my changes on my Ubuntu Feisty > setup which solved the problem. > -hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 > +hosts: files dns Thanks, this solved it. Making an strace on apt-get already showed that there was something strange going on regarding using of nss sub-libraries but I didn't know of /etc/nsswitch.conf which triggered that. Now I'm wiser :-) Thanks! -- Gruß... Tim. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Emacs work: porting to Maemo
Hello! > My questions: > > 1) does anyone have suggestions on this? I'm far from experienced > with X and GTK, and would appreciate any help at all. I'd be happier > concentrating on Emacs packaging, writing site-init scripts, etc. If > the Hildon experts could look at it, I'd be very relieved. Yes, it is possible to add support for the virtual keyboard for X11 applications not using Gtk. All you need is access to the X11 main event loop (you must be able to evaluate XClientMessages) and an application call back that calls you every time the application demands keyboard input (open virtual keyboard) and want to loose keyboard input (close virtual keyboard). The quoted code already contains the necessary code you retrieve keyboard input what seems to be missing is code to trigger the opening and closing which you can find in my code. I havn't found out all of the functionalities but current code is enough to get things working. See http://www.anderenen.de/anderenende/maemo.html for more information and ask me for details if you have problems with the code. > 3) how do I add the symbols to the key event loop? Right now, only > ASCII (7bit) makes it through, I think. The virtual keyboard input is UTF8. So that is not a problem of the virtual keyboard. Btw., other are right that there better editors to port for such a device but that is your decision ;-) -- Gruß... Tim. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] developing for 770 with IT2006 on Debian testing with 2.6.18 kernel
Hello! While I read aboutthis bug I'm using debian unstable with scratchbox 0.9.8.8 packages and Linux edge 2.6.18-3-k7 #1 SMP Sun Dec 10 20:17:39 UTC 2006 i686 GNU/Linux and using the 2007 scirocco development package and I'm at leats abel to fully run the emular and build packages for the Nokia 770. I don't know why and I havn't done anything special but it seems at leats for for my needs. -- Gruß... Tim. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Help on how to attach a non gtk+/hildon app to D-Bus
Hello! > Is it possible to initialize our C application (non GTK+/Hildon app.) and > attach it to D-Bus with libOSSO library? IMHO libOSSO is intermixed with Gtk so you must user Gtk somehow if you want libOSSO. Depending on your needs if might be enough to just initialize Gtk main event loop to get handling of DBus signals (quiting main event loop if your event has been reached). I'm not really a Gtk programmer so I can help you for that. > Where can we get an exemple on how to write a little C script to listen > D-Bus signals? If you want to have a rudimentary DBus just using select and no Gtk at all you can look at: http://illumination.svn.sourceforge.net/viewvc/illumination/trunk/Illumination/src/Lum/OS/X11/Display.cpp?revision=808&view=markup and watch out for "#if defined(HAVE_LIB_DBUS)" which marks the DBus specific parts. The module is mainly for X11 interaction but the DBus handling directly work with select and does not use X11 specific stuff. I'm not sure that the implementation is fully correct (found no good example) but at least I was able to get some events and did not see any error. If you have questions, mail me privately. I might improve the DBus implementation soon, if catching of screen blanking events requires that (see other thread). -- Gruß... Tim. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Alternative input method
Hello! > draw quikwriting layout there. Is there any maemo docs on this thing? I few days ago I send a mail to the list in the tread "Non-gtk application integration" that described a solution for non-gtk application to open (and close) the text input window and to receive virtual keyboard input. Please take a look at the archive... Communication between Application and and Virtual Keyboard uses X11 client messages. Looks like you have to emulate this. I got the information by using a special server proxy (xmon) that was placed between the client and the real (xephyr) server and that dumped all client messages between the given applications. I then had to analyse the raw protocol data trying by trying to find character codes and atom ids... Analysis was done using the desktop emulation. -- Gruß... Tim. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Non-gtk application integration
Hello! >> > * How can I trigger the keyboard when doing text entry ? I while ago i did some investigations regarding the communication protocol between maemo GTK applications and the keyboard by monitoring relevant X11 Client Messages to add support for keyboard handling funder maemo to my GUI library. I managed to get the keyboard openend and closed and get typed characters inserted into my application. I send these information a while ago to Antonio Gomes, the porter of the minimo browser. Antonio in turn managed to get keboard input working for minimo. This was (part of) my mail: -%<- OK, this source contains the necessary code fragment. http://svn.sourceforge.net/viewcvs.cgi/illumination/trunk/Illumination/src/Lum/OS/X11/Window.cpp?view=markup&rev=670 For the referenced files and classes you should also browse: http://svn.sourceforge.net/viewcvs.cgi/illumination/trunk/Illumination/src/Lum/OS/X11/ http://svn.sourceforge.net/viewcvs.cgi/illumination/trunk/Illumination/include/Lum/OS/X11/ And (top level): http://svn.sourceforge.net/viewcvs.cgi/illumination/trunk/Illumination/ The relevant code for opening the keyboard is in void Window::AcquireKeyboardInput() It reads a property from the desktop root window to find out the id of the input method window and then send some client messages to it. The outcomented messages were used by the example-toolbar program when opening the keyboard but I found out that one could miss some (their will have their purpose though. I assume further customizing). For closing the keyboard look at void Window::ReleaseKeyboardInput() If you have called AcquireKeyboardInput you will get in turn a number of of ClientMessages you have to evaluate or even answer. The relevant code starts with "Atom hildonWindow=XInternAtom(display->display,"_HILDON_IM_WINDOW",true);" which is called within bool Window::HandleEvent(::Lum::OS::EventPtr event) At that point you are right in the X11 event loop (for the window you have given the id of in the Acquire method). All code is not really cleaned up. I will put some common code into helper methods for cleanup. Here is a little text with information about the messages: Messages: _HILDON_IM_COM: l[1]: 0: Return pressed 1: Tab pressed 2: Backspace pressed 4: ??? 7: Session start? 12: Menu opened, reset? _HILDON_IM_ACTIVATE: l[0]: Client window to send input to l[1]: Window with current focus l[2]: 1: ??? 2: Close keyboard 3: ??? 4: Some kind of acknowlegde or "status change after typing"? 5: Close keyboard 6: 7: ??? (but uses l[3] as 'mode', can see no difference, but '0' is not allowed) 6: ??? (Results in getting COM-4 from keyboard!) 8: Session initiator? (uses l[3] as mode? '0' not allowed!) 9: Open keyboard (Perhaps "8" = "session begin" and "9" = "open"? 10: ??? 11: ??? 12: l[3] Mode flag (Bitset?): 1: only characters 2: Tab, return, backspace only 3: Letters and numbers (but no symbols) 4: only symbol characters 5: Everything but numbers 6: Only symbols and tab, return and backspace 7: everything 8: hexadecimal (A-F, a-f, 0-9) 9: Letters and numbers (but no symbols) (where is the difference to 3?) 10: A-F 11: letters and numbers (but no symbols) (where is the difference to 3 and 9?) 12: Hexadecimal and symbols 13: Everything 14: Hexadecimal and symbols 15: Everything 16: mathematical stuff (numbers, brackets, operators and letter 'w' and 'p'? 17: Letters, mathematical but no symbols 18: mathematical stuff but no numbers 19: Letters, mathematical, numbers but no symbols .. 31: The are many open points. For example there are messages to then the text context to the input method (for proper out completion). If you have questions or have extraced more information, please just mail me! -%<- Not ethat Illumination, the library that this source code is part of, also contains a lot of code showing how to use Gtk/maemo theming code for native (non-GTK) applications. While the code is neither perfect nor complete is shows how foreign applications can mimic maemo look & feel. Btw., It is not nice that maemo theming divergates from standard GTK theming. I hope that in future the differences between maemo and GTK theming will be removed or at least reduced (by either removing maemo GTK patches or getting them incorporated into GTK upstream). If there are any questions, ask. If anybody wants to add this information to some web page, feel free to do so. -- Gruß... Tim. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Missing library in the 2006 beta version?
Hello! > still wordering why are these libraries available on devel rootstrap (so > it makes possible to your app to depend on them) but not on the device > image ? Because they are normally used for session management (and general inter-process communication), but the maemo platform uses dbus for session management. You are right, if you don't have that session management on the device the SDK should not have it, too. Perhaps a simple packaging problem or some other tools in the SDK need them!? -- Gruß... Tim. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Missing library in the 2006 beta version?
Hello! > Most likely this is Autotools issue. At least older autoconf > checked the existence of X libraries by checking for libXt > and it added that also to the linker line. > > However, none of the modern (Gtk, Qt) UI toolkits use libXt > nor require it. Only something obsolete like Motif needs it. > Does your program really use/require libXt? The problem is the "AC_PATH_XTRA()" configure test. It defines the X_PRE_LIBS variable, which - from the documentation - contains libraries, which must be linked before you link the "regular" X11 libraries. The configure scripts for at least debian and maemo distributions returns "-lSM -lICE" for this variable. Configure scripts which try to be correct and portable and thus use this variable will automatically link against this libraries - even if they do not use them. I removed the use of X_PRE_LIBS temporary to avoid linking this libraries. Note also that recent versions of Xorg offer pkg-cocnfig *.pc files for the various X11 files. I plan to use them if available and fall back to AC_PATH_XTRA if not. These *.pc files do not show above behaviour of automatically adding -lSM and -lICE. I do not have any problem with libXt. -- Gruß... Tim. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Porting non-GTK applications to maemo
Hallo! As the subject tells I want to port some of my applications to maemo. However my applications do not use Gtk but my own GUI library which uses direct X11 calls. As the result I cannot directly follow the porting guide which requires the use of libosso (using Gtk objects) or the parts of the Hilton framework that directly use Gtk objects. As a consequence I have a number of questions: * Is this possible (IMHO it should)? * What are the minimal requirements for my applications to interwork? + I assume that I have to open a D-BUS session on start and need to handle certain calls for application session management. Is this documented? + I likely have to fiddle around with the enhanced X input models to get input from the virtual keyboard. I already do support the enhanced X11 input stuff, but possible I need to do more. Is there any detailed information about this or even an X11 code example I could check? + I have to write a maemo desktop file. + I have to create debian packages for my library and for each application. + I have to support or emulate hilton menu and toolbar stuff. Is this required? Is the relevant part of the application (do I just need to draw my menues and tools bars the "hilton way"?) or is this external to application (some special atoms for the X11 window manager or similar)? + Is there more I need to support? -- Gruß... Tim. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
