Broken packages in Extras repository
There are some broken packages in Extras repository which which are preventing some applications from working. First there is issue libsdl-ttf2.0-0 vs. libsdl-ttf2.0 packages. At some point Nokia has included libsdl-ttf2.0 package in SDK and their repositories while Extras already had libsdl-ttf2.0-0 (which I believe to be the correct name because it is used in Debian). These packages are of course conflicting and older packages depend on Extras package and newer on Nokia package. Attila Csipa handled this issue in earlier mail. Extras maintainer has updated his package to a dummy package which depends on Nokia package which fixes the problem. Updated package is found only from extras-devel and it's not going to promoted to Extras with normal procedures in near future so somebody who can should go and promote it.. Then there is python-numpy, which seems to be completely unfunctional. import numpy fails after installing it. After installing mypaint numpy seems to work, so python-numpy has broken dependencies. Unfortunately there is updated python-pygame which uses numpy. So import pygame fails too, which breaks all pygame applications (if mypaint is not installed). Pygame automatically tries to use numpy, if it's installed. To fix this situation I think somebody should fix numpy package and fast track promote it to Extras. These packages have been broken for months according to time stamps in packages interface. These fixes would only help those who already haven't installed broken packages, rest of the users would need to first remove some applications and then reinstall them. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Broken packages in Extras repository
On Sat, Sep 4, 2010 at 6:07 PM, Attila Csipa ma...@csipa.in.rs wrote: Unless I'm grossly mistaken, that does not solve the problem. First of all, most apps depending on it do not depend on it as a version, so H-A-M will never update it on it's own, even if the newer version is in Extras. Second, if you already installed, you will not be able to update as the package in the nokia repo has no provides/replaces clause, so apt will fail as it will try to overwrite a file already existing in the package that triggered the upgrade. https://bugs.maemo.org/show_bug.cgi?id=10450 is quite silent so I might need to poke someone (kinda tried that last week, but apparently wasn't adamant enough :) Yes I realise that it doesn't solve the problem completely. Currently Extras is broken for everybody, but if we promote libsdl-ttf2.0-0, Extras is fine for people who haven't installed libsdl-ttf2.0(-0) or have the ability uninstall it. After 2 months something could be done? Unless this leads to even worse situation. -- Mikko Vartiainen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Hildon-Desktop: added Widget not shown
Not sure about that - I just tested it on my 44-1 and all previously placed custom widgets came up again. I also was able add other previously installed widgets. What was your test case so that I can better try and verify on my device? Hmm, it seems that sometimes widgets disappear, not always.___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Hildon-Desktop: added Widget not shown
Notice that hildon-desktop does not have any plugins, all plugins are in hildon-home. What you need is killall hildon-home -- it will restart automatically and no reboot is needed. That's good to know. So does that mean we can put this on a postinst script and it will not affect running applications and other C applets? Not very good method since it disables all non-nokia widgets. -- Mikko Vartiainen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Hildon-Desktop: added Widget not shown
(Resent with correct time/date) Hello all I've uploaded an alpha version of my shutter home widget (IR shutter for Nikon DSLR) to extras-devel. Functionaly, it works. But now I have a small problem in my installer that I'm unable to resolve: After running the deb, the widget gets installed. It can then be added to the desktop by the user through the normal Desktop Config Add Widget process. It shows up in the list and is selectable. But then it does not show up on the desktop! However, once the device is rebooted, the added widget is cleary visible and works well. Now I really don't want to forece my users to reboot just because of a widget. Therefore my question: what am I missing? Any special postinstall script to run? I think it's still possible that hildon-desktop python-loader doesn't work after it's insalled until device (or hildon-desktop) is restarted. I've seen similar reports related to other python based widgets. Since it happens only once it's hard to really notice. Does any python developer know anything about this? -- Mikko Vartiainen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Hildon-Desktop: added Widget not shown
On Tue, Jan 12, 2010 at 10:51 PM, Anderson Lizardo anderson.liza...@openbossa.org wrote: Well, we have never got reports on this (it's the first report I see about this). If you could point to the other reports of python widgets not working without a reboot that would be nice. Problem is that there isn't reliable bug reports (about openvpn-applet and touchsearch for example), just random forum messages. But I've experienced it myself, but I thought that it was fixed with the latest versions. To make a reliable test I would need to reflash whole device (rootfs+emmc) and I'm not very keen to do that. -- Mikko Vartiainen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Hildon-Desktop: added Widget not shown
On Wed, Jan 13, 2010 at 2:18 AM, Anderson Lizardo anderson.liza...@openbossa.org wrote: This is the expected behavior. You need the Python loader (provided by the hildon-desktop-python-loader) installed *and* loaded in order to have Python applets recognized. The problem (as I mentioned on the other message) is probably that the hildon-desktop process is not being aware of the new loader until it is restarted. A possible test case (which I cannot test ATM) is: 1) apt-get remove hildon-desktop-python-loader 2) Restart N900 3) apt-get install hildon-desktop-python-loader 4) Install some Python applet The let us know if the applet is shown or not. I used TouchSearch and OpenVPN Applet as testcase. TouchSearch is desktop widget and OpenVPN Applet is status menu widget. 1. apt-get remove python2.5 2. killall hildon-desktop hildon-home hildon-status-menu 3. HAM install TouchSearch 4. TouchSearch didn't appear in desktop or in widget list 5. HAM install openvpn-applet 6. openvpn-applet appeared in status-menu (with broken icon) 7. HAM uninstall touchsearch, HAM install touchsearch 8. TouchSearch didn't appear anywhere 9. killall hildon-desktop hildon-home hildon-status-menu 10. TouchSearch appeared in desktop. openvpn-applet had it's icon shown properly (just another side effect of removing icon cache :( ) Status menu widget worked and desktop widget didn't work. I thoght I had tested this earlier and that desktop widget were working too, apparently that was not the case. -- Mikko Vartiainen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder is broken again
I don't know what happened, but I've seen about 15 builds using only i386 architecture. Now it's OK again, so I think that change was reverted back. Is it possible that you were referring to python applications such as gonvert, quicknote and dialcentral? They are using Architecture: all so they are built only once using the i386 builder. -- Mikko Vartiainen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: is 44-1 officially going to be available as an image ?
Any idea why my n900 doesn't see the update? Have you accidentally removed SSU metapackage (mp-fremantle-generic-pr)? -- Mikko Vartiainen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify with Chinook / conditionals in debian/rules
Hi, I'm trying to optify Conboy and noticed that maemo-optify does not exist on Chinook. So I've added the build dependency like that: Build-Depends: [...] maemo-optify | maemo-version-dev ( 5.0) Currently it's possible to simply add debian/optify file and put auto there. Builder will optify package for fremantle and ignore the file for other targets. No need for deps or rules changes. -- Mikko Vartiainen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify with Chinook / conditionals in debian/rules
I have generally put maemo-optify in the rules file right after dh_builddep as mentioned in the README. It may be true that the builder doesn't need it, but it appears the SDK does (?). Builder runs maemo-optify-deb which you can run locally too if needed. -- Mikko Vartiainen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Pushing optified Python libs
This is bad manner and utterly evil. User _applications_ should be in user/* categories. (Basically everything you want the end-user to see and be able to uninstall) Everything else should never be in user. There is or is going to be user/hidden category http://maemo.gitorious.org/hildon-application-manager/mainline/commit/f7b4542b3c77114a95e2803708cec8eeff3409f7 The easiest way to update the python libraries for now is to either promote an application depending (= the new version) or ping me to manually push them through. It's the easiest way but at the same time it's practically impossible or at least very hard for such libraries as python. This thread is a good reference for python updating difficulties http://maemo.org/community/maemo-developers/qa_process_for_non_user--packages_and_how_application_manager_handles_upgrades-was-re-extras-devel--extras-testing_auto-promotion_not_working/ -- Mikko Vartiainen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Pushing optified Python libs
However, we've just hit a major regression caused by an attempted Python optification bugfix with failed QA. Although I believe the issue has been solved now, I think we need to sit on the package in extras-devel for a week or so before pushing it to testing (Python optification is implemented in a manner that optification bugs may cause a systemic failure in the whole Python subsystem). Pymaemo-optify 0.2 has landed Extras (or at least Downloads) http://maemo.org/downloads/product/Maemo5/pymaemo-optify/ What happened here and how it's even possible? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Pushing optified Python libs
On Fri, Dec 18, 2009 at 9:44 PM, Niels Breet ni...@maemo.org wrote: An application depending on python2.5-minimal got promoted to Extras from -testing. Python2.5-minimal depends on pymaemo-optify, so that got promoted too. Then it was Panucci though a series of dependencies that I can't quite follow. I would have assumed that it wouldn't trigger updating of python2.5-minimal. The question is why it shows up in Downloads as it is in section devel and not in a user/* section. This is something I need to check more closely as that seems to be a bug in the importer for Downloads. Seems very similar than XB-Maemo-Upgrade-Description is displayed way too soon https://bugs.maemo.org/show_bug.cgi?id=6187 -- Mikko Vartiainen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Pushing optified Python libs
would there be a possibility to push them to Extras forcing an update in the background? It may be again noted that pushing library updates for end users is practically impossible because Application Manager doesn't update packages which are not in user/* category. -- Mikko Vartiainen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Pushing optified Python libs
BTW, I tested putting packages in user/hidden category and indeed (albeit autobuilder complaining about the unknown category) application manager recognizes new versions of packages in that category (showing the update notification and allowing to upgrade). Pymaemo-optify shows up for me at Other category as would any other non-standard user/ category. So I would say that user/hidden is not (yet?) implemented. Not sure if it is the best/correct solution though, as it looks like undocumented. Hidden category doesn't help pushing pymaemo-optify updates for those users who don't have it already installed. But it can be used for pushing updates for packages which are not supposed to be visible in installable packages. To get normal updates, all non user/* packages should be moved to user/hidden. Then I would wonder what's hidden category be good for when same behaviour would be achieved by simply updating all packages, no matter which category they are in. :) -- Mikko Vartiainen___ 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?)
On Thu, Dec 3, 2009 at 3:42 PM, Anderson Lizardo anderson.liza...@openbossa.org wrote: * If I understood Mikko's explanation right, HAM will not upgrade a dependency automatically (unlike apt-get upgrade), unless a installed (or to be installed) user/* application exclicitely Depends on that new version (i.e. uses Depends: package (= x.y), where x.y is the newer version). If that's correct, each new version of a dependency that contains a important fix will require *all* Python applications updating their versions to include the new required version in debian/control, if we want the user to have that fix. Mikko: feel free to correct me if I made a mistake. Yes, you understood correctly. * installing this metapackage will obviously install *all* PyMaemo packages, which will take unnecessarily precious storage even if not all packages are used. But this user/hidden (which I've never heard of) is different. It seems that user/hidden packages get the same treatment as other user/ packages for updates, but they cannot be separately installed. User/hidden pacakge could be part of the solution, but it's still awkward and unnecessary hack compared to normal upgrades. If user/hidden was used all python apps should depend on big pymaemo metapackage, which would pull all packages even if not needed as you said. But if user/hidden is already (or soon) there, it might be the best option available. After all application space isn't big issue anymore, and after installing 2-3 python application you have practically installed all pymaemo packages anyway. -- Mikko Vartiainen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras-devel - extras-testing auto-promotion not working?
Well, it *used* to work like that some time ago, but in the last weeks I've noticed that no newer versions of PyMaemo packages (which are all dependencies from various user/* application) got promoted as before. Packages don't get updated in promotion process if earlier version satisfies dependency. Many packages have direct dependency only for python package, which hasn't been updated lately, not for python2.5 which is the actual optified version. python2.5 isn't probably promoted because no package hasn't had dependency python2.5 (=2.5.2-3maemo3). If packagers like to keep their Depends line clean they are unlikely to put python2.5 directly there. -- Mikko Vartiainen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras-devel - extras-testing auto-promotion not working?
On Tue, Dec 1, 2009 at 3:37 PM, Anderson Lizardo anderson.liza...@openbossa.org wrote: Should I proceed and promote the missing PyMaemo packages to extras-testing ? You can promote PyMaemo packages to extras-testing but it's not the solution, because it doesn't help getting them to Extras (you can't promote them there). Even if newer versions of non user/ packages were promoted to Extras it doesn't help much getting them to end users devices if they had earlier version of them installed because of how Application Manager works. Currently getting something to updated requires that update is somehow visible through user/ package both in Application Manager and packages interface autopromotion algorithm. Promotion system could probably be changed that it always promotes newer version of non user/ package. One option would be that package maintainer can promote updates of non user/ package to extras manually, but that circumvents the whole qa process. -- Mikko Vartiainen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras-devel - extras-testing auto-promotion not working?
On Tue, Dec 1, 2009 at 4:08 PM, Igor Stoppa igor.sto...@nokia.com wrote: But if here there is a clear bug (not using /opt) which gets fixed by the newer version, what more is needed? And why? For this particular case there isn't anything else needed (imo). But generally if you can't promote user/ packages directly to extras you probably shouldn't be able to promote non user/ packages directly either. -- Mikko Vartiainen ___ 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?)
I still suggest meta user/* packages. Nokia is actually using meta user/* packages (for example, Maemo 5 package is a meta package pulling the platform non user/* packages when upgraded). Meta packages are unfortunately the only working way get library updates to users. I still would hate to see all libraries in Application Manager, even if they were semi hidden to some category. Only _good_ solution that I can see is that Application Manager would work the same way as apt-get and upgrade all packages (except the Nokia meta package). -- Mikko Vartiainen ___ 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?)
On Tue, Dec 1, 2009 at 5:39 PM, Anderson Lizardo anderson.liza...@openbossa.org wrote: The problem being that the meta-package will pull *all* PyMaemo packages and not just what the user wants/needs :/ Yes, meta packages would bring more problems than solve them. Unless Application Manager honours Suggests: fields ? in this case we could put all non-core Python packages under that field. I don't think HAM knows about suggests field. The other solution is to fix Application Manager :o) IMO Application Manager is broken from community (Extras) perspective. From Nokia's perspective it's probably not broken because they can control that single meta package for SSU. How could we get that fixed? --- Mikko Vartiainen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-release
How can I differentiate between arm and x86 builds? Example - x86 may use vorbis package but arm can use tremor so Build-Depends: can be different for x86 vs ARM. arm may also benefit from arm specific compiler flags. How can I solve that? I'm not sure why would you want to do that in maemo context. You should be able to define architecture specific depencies this way Build-Depends: package-name [armel], package2 [!armel]. Haven't actually tested it, but I think it should work. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Optification breaks package on upgrade from non-optified older version
On Fri, Oct 16, 2009 at 2:05 PM, Andrew Flegg and...@bleb.org wrote: On Fri, Oct 16, 2009 at 11:49, Mikko Vartiainen mvartiai...@gmail.com wrote: This would certainly work. maemo-optify should have option which prevents it from creating directory links. Why would/should it be an option? From the sounds of it, it shouldn't create directory symlinks; why would a package ever want them given the problems it can cause? Other way around then. Option to create directory symlinks. They are useful for large data directories with hundreds or maybe thousands of files. Currently maemo-optify doesn't create links for files which are smaller than 2KB, but there could be hundreds (or thousands) of small files. Of course it's possible to install to /opt without using maemo-optify but I find it very easy use. -- Mikko Vartiainen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: VFP in autobuilder enabled?
Can you point me out to them and explain how did you find out that they are built without vfp? OK, thanks for the clarification. I was jumping to conclusions. I just noticed that fremantle didn't have vfp in DEB_BUILD_OPTIONS like it was in chinook and diablo autobuilder. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: VFP in autobuilder enabled?
2009/6/25 Jeremiah Foster jerem...@jeremiahfoster.com: Hello, I was asked on irc in #maemo if the fremantle autobuilder supports DEB_BUILD_OPTIONS=vfp. It appears that it does not and many of the applications in the repos in fact set that option. Can someone confirm that the autobuilder supports DEB_BUILD_OPTIONS=vfp? $ grep vfp /etc/sbdmock/*-devel.cfg /etc/sbdmock/maemo-chinook-armel-extras-devel.cfg:config_opts['env']['DEB_BUILD_OPTIONS']=maemo-launcher,thumb,vfp,parallel=4 /etc/sbdmock/maemo-diablo-armel-extras-devel.cfg:config_opts['env']['DEB_BUILD_OPTIONS']=maemo-launcher,thumb,vfp,parallel=4 Question is why vfp is not enabled? Just a bug? Anyway there's bunch of packages in fremantle extras-devel which are built without vfp and they would need to be rebuilt... -- Mikko Vartiainen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Continued problems with python dependencies
Quim Gil wrote: I'm testing with fremantle extras-devel repo installed in one of those developer units, not on SDK. GPodder can't be installed today: Application packages missing: python-support ( 0.90.0) Same for MyTube and mediabox among others. python (= 2.5.2-3maemo2) and python2.5 (= 2.5.2-15maemo3) are missing dependencies for maemo-python-env, in addition to python-support ( 0.90.0) In practice, no Python app works from the many uploaded to extras-devel. In SDK both gpodder and mytube can be installed fine. Mediabox cannot be installed because there is no mplayer. None of the apps should pull maemo-python-env as a depency. Are you sure that the installation is in consistent state? Are you trying to install with apt-get? I would do apt-get update and try to install with apt-get install. If that doesn't work full apt output would be helpful. -- Mikko Vartiainen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Continued problems with python dependencies
just as a side note, perhaps it's related: The units we saw at the danish weekend only had the extras-devel repo but not the original nokia repos installed. So everything requiring stuff from other repos than extras-devel was not installable. This is possible cause. All of the packages in extras-devel assume that SDK repository is available. This is false assumption for the device, but it has to be made because there is no way of knowing what is preinstalled to device or available from possible default repositories. apt output would help to diagnose the problem. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder broken or what?
Where does this package come from? Actually it comes from the the repository of the guy that has ported KDE to Maemo.(http://www.kdedevelopers.org/node/3624) So this has actually never shipped with a distro? Is it the client or server part of mysql? Or both? both ones. But I'm going to remove the server package. You can then change the name to mysql-5.0_5.0.32-0maemo3, you do not need the dfsg designation which appears to mean debian free software guidelines. If you just package the client, you can call it mysql- client-5.0_5.0.32-0maemo1 so that users will know it is not the whole mysql-common package. It's called mysql-dfsg because it's a source package and the source package in debian is also called mysql-dfsg, see http://packages.debian.org/lenny/mysql-client-5.0 for example. mysql-common, mysql-client etc binary packages are built from this source package. So no reason to change names imo. btw. I wouldn't remove the server package if it builds, somebody will want it anyway. -- Mikko Vartiainen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: debmaster priorities [YOUR INPUT HERE]
The backend stuff is pretty important. For example, when building packages for fremantle, certain things have changed. This means that packages that are needed as dependencies are not getting built because they are not conforming to the new rules. What are these certain things or rules? I don't recall or haven't even noticed that there is something new for depencies (which are mostly libraries). -- Mikko Vartiainen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
