Re: Considering /opt and MyDocs in your packages
On Thu, 2009-09-10 at 17:20 +0200, Vollmer Marius (Nokia-D/Helsinki) wrote: ext Andrew Flegg and...@bleb.org writes: Although a unionfs solution would be a bit more further dev on Nokia's part, it will reduce the developer complexity and gives us a real world solution now. I'm sure the community would help as well, with patching/building/testing kernel modules (once again, Nokia should realise there are clever technical people in the community who could help design an optimal (= quick good) solution if engaged at the right time). Yes, agreed. Let's give this unionfs thing a shot. I was previously arguing against it, but only as a long-term solution. As a Fremantle-only hack, it might be better than the /opt hack. Does UnionFS support block rotation (like ubifs) for the internal flash? -Kimmo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Problem in Building Application
On Fri, 2009-09-11 at 07:43 +0200, ext Venugopal Rao Gubbala wrote: Hi, I am new to maemo Platform. I have downloaded mweather application from garage and while trying to build it I am getting Following error. I am getting error while running ./configure. It says No package 'hildon-lgpl' found Can any one tell me how to fix this issue or how to install hildon-lgpl. I tried googling but was not successfull. hildon-lgpl has been removed 2.5 years ago, please use libhildon1 instead. -Kimmo Maemo 5 installed on my system and Operating System is Ubuntu Jaunty. Command prompt out put is :: [sbox-FREMANTLE_X86: ~/App/mweather] ./autogen.sh + libtoolize --automake + aclocal-1.7 -I m4 + intltoolize --automake + autoconf + autoheader + automake-1.7 --add-missing --foreign [sbox-FREMANTLE_X86: ~/App/mweather] ./configure checking for a BSD-compatible install... /scratchbox/tools/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for style of include used by make... GNU checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking for gcc option to accept ANSI C... none needed checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking dependency style of gcc... (cached) gcc3 checking how to run the C preprocessor... gcc -E checking whether make sets $(MAKE)... (cached) yes checking whether ln -s works... yes checking for a BSD-compatible install... /scratchbox/tools/bin/install -c checking whether NLS is requested... yes checking for intltool = 0.21... 0.40.5 found checking for intltool-update... /scratchbox/devkits/doctools/bin/intltool-update checking for intltool-merge... /scratchbox/devkits/doctools/bin/intltool-merge checking for intltool-extract... /scratchbox/devkits/doctools/bin/intltool-extract checking for xgettext... /scratchbox/tools/bin/xgettext checking for msgmerge... /scratchbox/tools/bin/msgmerge checking for msgfmt... /scratchbox/tools/bin/msgfmt checking for gmsgfmt... /scratchbox/tools/bin/msgfmt checking for perl... /scratchbox/tools/bin/perl checking for XML::Parser... ok checking build system type... i486-pc-linux-gnu checking host system type... i486-pc-linux-gnu checking for a sed that does not truncate output... /scratchbox/tools/bin/sed checking for grep that handles long lines and -e... /scratchbox/tools/bin/grep checking for egrep... /scratchbox/tools/bin/grep -E checking for ld used by gcc... /scratchbox/compilers/cs2007q3-glibc2.5-i486/i486-pc-linux-gnu/bin/ld checking if the linker (/scratchbox/compilers/cs2007q3-glibc2.5-i486/i486-pc-linux-gnu/bin/ld) is GNU ld... yes checking for /scratchbox/compilers/cs2007q3-glibc2.5-i486/i486-pc-linux-gnu/bin/ld option to reload object files... -r checking for BSD-compatible nm... /scratchbox/compilers/bin/nm -B checking how to recognize dependent libraries... pass_all checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for xlf95... no checking for f95... no checking for fort... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of
Re: Considering /opt and MyDocs in your packages
Kimmo Hämäläinen wrote: Does UnionFS support block rotation (like ubifs) for the internal flash? UnionFS works on top of other file system(s) in directory level. In this case, UBIFS would be still there for the underlying root filesystem. It seems that the overhead of using UnionFS is about 10% [1], which should be noted when making decisions. This performance lost will affect all files, not should optified files as in the original plan. BR, Henrik [1] http://www.linuxjournal.com/article/7714 -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
On Fri, 2009-09-11 at 09:15 +0200, ext Henrik Hedberg wrote: Kimmo Hämäläinen wrote: Does UnionFS support block rotation (like ubifs) for the internal flash? UnionFS works on top of other file system(s) in directory level. In this case, UBIFS would be still there for the underlying root filesystem. It seems that the overhead of using UnionFS is about 10% [1], which should be noted when making decisions. This performance lost will affect all files, not should optified files as in the original plan. Maybe it could be used selectively for installed applications only. I think the 10-12% speed loss is not going to be accepted for all file system access (doesn't make sense either if it can be avoided). -Kimmo BR, Henrik [1] http://www.linuxjournal.com/article/7714 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
David Weinehall wrote: IMHO we have three options: - Real VFAT (with all the drawbacks it brings) - VVFAT - A separate program (PC Suite, most likely) to do the transfers (probably leaving Linux and MacOS users out in the cold) There is also MTP [1]. It is less generic than one would want but still it tries to solve this problem. Too bad there is no generic USB standardized filesystem gadget. 1. http://en.wikipedia.org/wiki/Media_Transfer_Protocol ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
Andrew Flegg wrote: ...because /opt is a hack because no-one at Nokia had the foresight to imagine that users might want to install multiple applications, and large new frameworks like Qt. It wasn't really hard to see this coming. We are booting from MMC since the OS2006 days and one of reasons users do it is that the space in internal NAND is too small. 3 years later someone noticed this problem and we have this ugly /opt hack done in last minutes. Oh well ;-) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
ext Andrew Flegg and...@bleb.org writes: On Thu, Sep 10, 2009 at 16:12, Marius Vollmer marius.voll...@nokia.com wrote: ext Andrew Flegg and...@bleb.org writes: Instead of using a fixed prefix of /opt/maemo/path, use /opt/package/trimmed path. [big snip] I'm not going to get into a point-by-point rebuttal of these. Hmm, I am really in a detail-oriented let's get this done mode. As I said, the question of whether or not and if so how to use /opt for distribution packages is bigger than this, and I don't think we should try to answer it here. People haven't really used /opt in their packages until now, and nothing really has changed to reconsider this on a massive scale. The name /opt that appears in this discussions is a big giant red herring. Just pretent it really was /space all the time, and I hope you can see how different the discussion would have been. But installing stuff in /opt on Maemo by third-parties isn't really going to happen. Maybe not, but that's no reason to repurpose the whole of /opt. You could also say that Maemo will never really be multi-user, but that's no reason to get rid of /home/user. We own the space, pretty much everything is going to be installed from packages, and we already make all manner of assumptions in a Linux system that there's some unique UNIX name for a package. Why *not* make the one-line change to maemo-optify to make its results slightly cleaner? Because it's not cleaner in my view, it would be an even bigger abuse of /opt than hiding things in /opt/maemo. If you really care, we can make this an option to maemo-optify, and you can use it in your packages. I will still recommend the default of just moving everything to /opt/maemo without any further distortion. - Computing the trimmed path from path is an extra complication, and we must make sure that no collisions happen. It's doable of course, but in the light of the arguments above, why bother? ...because /opt is a hack because no-one at Nokia had the foresight to imagine that users might want to install multiple applications, and large new frameworks like Qt. The /opt is hack statement needs to be qualified, of course. Moving stuff into /opt/maemo is a hack, of course. But at least in my opinion, Moving stuff into /opt/package/ is a bigger hack, and a bigger violation of the letter and spirit of /opt. *shrug* ...because /opt is a hack which should be *embarassing*. It is! ...because maemo-optify creating a forest of symlinks is messy, unelegant and possibly prone to failure (see my earlier question about Python modules and sub-directories of optified packages). If I understand your proposal here right, we would still have the same forest of symlinks, just more messy since they have a more complicated pattern. Mainly, though, because last minute fixes shouldn't throw good design out of the window. I don't think using /opt/package in distribution packages is good design. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
ext Andrew Flegg and...@bleb.org writes: On Thu, Sep 10, 2009 at 16:20, Marius Vollmer marius.voll...@nokia.com wrote: ext Andrew Flegg and...@bleb.org writes: Although a unionfs solution would be a bit more further dev on Nokia's part, it will reduce the developer complexity and gives us a real world solution now. [...] Yes, agreed. Let's give this unionfs thing a shot. I was previously arguing against it, but only as a long-term solution. As a Fremantle-only hack, it might be better than the /opt hack. Cool. I should also point out that when I say a unionfs solution, I mean a union FS solution; rather than advocating unionfs over aufs (for example). Thanks to Stskeeps/Carsten for picking me up on that. Noted, thanks! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
ext Graham Cobb g+...@cobb.uk.net writes: On Thursday 10 September 2009 12:16:59 Marius Vollmer wrote: Also, you can make it so that maemo-optify only runs in debian/rules when it is present: which maemo-optify maemo-optify Small correction: that doesn't work (because it returns an error status when maemo-optify is not present). Right, sorry for hastily posting untested code. (I should know better not to do that.) Is the idea that the autobuilder will automatically install maemo-optify if it exists for that version or do we have to add it to our Build-Depends? Good question. I haven't really thought this through, obviously... :-/ Right now I would say that the buildbot should automatically install it, but maybe that is a bit brittle. What about uploading a version of maemo-optify to all buildbots, and only the one in Fremantle does any actual optification? Or we could do something more general ala the type-handling package in Debian. We could have a package that Provides virtual packages like fremantle, not+fremantle, diablo, not+diablo as appropriate for the distribution it is in, and then packages can have Build-Depends like Build-Depends: maemo-optify | not+fremantle Might be overkill, dunno. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
Marius Vollmer (marius.voll...@nokia.com) wrote: The /opt is hack statement needs to be qualified, of course. Moving stuff into /opt/maemo is a hack, of course. But at least in my opinion, Moving stuff into /opt/package/ is a bigger hack, and a bigger violation of the letter and spirit of /opt. *shrug* Uh, I am not sure about this. Reading the Filesystem Hierarchy Standard (http://www.pathname.com/fhs/) it seems that both uses (/opt/maemo/* and /opt/package) are covered by it. In fact configuring applications with --prefix=/opt and installing to /opt is not. (for /opt/maemo one apparently should register maemo with http://www.lanana.org/ which is apparently not really a problem: nokia and nokiasiemensnetworks are already registered) I don't think using /opt/package in distribution packages is good design. True. Bye, Simon -- si...@budig.de http://simon.budig.de/ simon.bu...@kernelconcepts.de http://www.kernelconcepts.de/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
ext Simon Budig si...@budig.de writes: Marius Vollmer (marius.voll...@nokia.com) wrote: The /opt is hack statement needs to be qualified, of course. Moving stuff into /opt/maemo is a hack, of course. But at least in my opinion, Moving stuff into /opt/package/ is a bigger hack, and a bigger violation of the letter and spirit of /opt. *shrug* Uh, I am not sure about this. Reading the Filesystem Hierarchy Standard (http://www.pathname.com/fhs/) it seems that both uses (/opt/maemo/* and /opt/package) are covered by it. Yes, but package is not in the same namespace as the distribution packages. As you point out, one should register the package names with Lanana. (I didn't know about this, thanks for the information.) I feel confident that we can get away with maemo without registering it. Using /opt/nokia feels wrong, since it gives the impressions that everything under /opt/nokia is actually provided by Nokia, which isn't true, and strictly speaking we would have to use /opt/nokia/maemo anyway since /opt/nokia is for all of Nokia, not just for our little hack here. Anyway, let's not discuss this to death. Patches to maemo-optify are welcome as long as they don't change the current default behavior of putting things in /opt/maemo. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
On Fri, Sep 11, 2009 at 08:15, Henrik Hedberg henrik.hedb...@innologies.fi wrote: It seems that the overhead of using UnionFS is about 10% [1], which should be noted when making decisions. This performance lost will affect all files, not should optified files as in the original plan. The article in question *is* five years old, and I believe the preferred union FS solution wouldn't be UnionFS, it'd possibly be aufs or one of the others explored by Valerie. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
On Fri, Sep 11, 2009 at 11:11 AM, Marius Vollmer marius.voll...@nokia.com wrote: ext Graham Cobb g+...@cobb.uk.net writes: On Thursday 10 September 2009 12:16:59 Marius Vollmer wrote: Also, you can make it so that maemo-optify only runs in debian/rules when it is present: which maemo-optify maemo-optify Small correction: that doesn't work (because it returns an error status when maemo-optify is not present). About the maemo-optify usage. The opkg package manager support a offline root mode that allows you to install packages using a different base. The idea is that one might want to install some content on a removable media. it doesn't require you to change the packages. perhaps this is a less intrusive option? Greetings ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
ext Kees Jongenburger kees.jongenbur...@gmail.com writes: The opkg package manager support a offline root mode that allows you to install packages using a different base. Like dpkg's --root option? The idea is that one might want to install some content on a removable media. it doesn't require you to change the packages. perhaps this is a less intrusive option? Nah, come on now. None of the packages will work if you install them somewhere else than in /. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
Hi, I don't think /opt/package is a bad idea, and I wouldn't call it a hack. On other Unices, like Solaris, 3rd party software usually goes to /opt. In fact, by default, /usr is write-protected in virtual containers (mounted read-only from the host system). The good thing IMHO about /opt is that all stuff resides in one place, not being scattered all across the filesystem. When looking at Solaris, you can find directories like lib and bin inside /opt/package/. This way it's also possible for programs to bring in libraries that would otherwise break or mess up the root system. LD_LIBRARY_PATH, etc. can be setup by the start scripts of the programs accordingly. I'm all for keeping the root system clean of 3rd party stuff. Regards, Martin 2009/9/11, Kees Jongenburger kees.jongenbur...@gmail.com: On Fri, Sep 11, 2009 at 11:11 AM, Marius Vollmer marius.voll...@nokia.com wrote: ext Graham Cobb g+...@cobb.uk.net writes: On Thursday 10 September 2009 12:16:59 Marius Vollmer wrote: Also, you can make it so that maemo-optify only runs in debian/rules when it is present: which maemo-optify maemo-optify Small correction: that doesn't work (because it returns an error status when maemo-optify is not present). About the maemo-optify usage. The opkg package manager support a offline root mode that allows you to install packages using a different base. The idea is that one might want to install some content on a removable media. it doesn't require you to change the packages. perhaps this is a less intrusive option? Greetings ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
ext Martin Grimme martin.gri...@gmail.com writes: I don't think /opt/package is a bad idea, and I wouldn't call it a hack. On other Unices, like Solaris, 3rd party software usually goes to /opt. In fact, by default, /usr is write-protected in virtual containers (mounted read-only from the host system). I like to see Maemo as a traditional, all-inclusive distribution. As such, the stuff in Maemo Extras is as 1st party as any other package. (True, some package are more equal than others, such as the OS meta-packages, and some repositories are also more equal than others, such as the System Software Updates repo, but these things are not really Us vs You.) The good thing IMHO about /opt is that all stuff resides in one place, not being scattered all across the filesystem. That's just on the surface. If you have a reasonable package management system, it doesn't make any difference either way. I do agree that the traditional Unix filesystem layout is not very clean, but it is also not broken and I don't want to try to fix anything about it within this excersize of finding more space for applications. When looking at Solaris, you can find directories like lib and bin inside /opt/package/. This way it's also possible for programs to bring in libraries that would otherwise break or mess up the root system. They can do this without /opt as well, of course. LD_LIBRARY_PATH, etc. can be setup by the start scripts of the programs accordingly. I'm all for keeping the root system clean of 3rd party stuff. Knock yourself out, I am not stopping you. :-) But I also don't want to make this optification any more complex than it needs to be, for the sake of something non-trivial and fuzzy as cleaning up the Unix filesystem layout. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
On Fri, Sep 11, 2009 at 10:32, Marius Vollmer marius.voll...@nokia.com wrote: Yes, but package is not in the same namespace as the distribution packages. As you point out, one should register the package names with Lanana. (I didn't know about this, thanks for the information.) No, according to the FHS provider needs to be registered with LANANA, not individual packages (and so only if you use /opt/provider/package). Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
On Friday 11 September 2009 09:56:14 Marius Vollmer wrote: Hmm, I am really in a detail-oriented let's get this done mode. As I said, the question of whether or not and if so how to use /opt for distribution packages is bigger than this, and I don't think we should try to answer it here. So, given all the controversy and discussion, why don't we start with the simple hack. Let's decide that for the short term, any package (or group of packages forming an application) which is over (say) 500K SHOULD (not MUST) use the maemo-optify hack or some other mechanism to put most of its data somewhere in /opt. Yes, I hate all the symlinks but it will do the job for now. But don't try to force it on all applications, or do it automatically. Just get the maintainers of the big, commonly installed apps to agree to use the hack for now. I am assuming that there is no way that, at this late stage, Nokia would even consider any serious changes to filesystems (such as union filesystems, etc.). So, much of this discussion is about how it can get fixed in the medium term. The **really** interesting question is going to be whether someone can come up with a solution which Nokia can (and will agree to) apply in a Fremantle update! Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
