base-files/fstab, must mount proc before using auto

Busybox's mount uses /proc/filesystems to determine a list of possible
filesystem to try when mounting filesystems of type "auto"

Two of the fstab's specify a mount point of type "auto" prior to
specifying the proc entry, this breaks "mount -a" behaviour.

The attached patch moves proc up above the "auto" entries so mount can
get the filesystem list prior to the "auto" entry.

"mount -a" will work again for generic and collie

Glenn

--- a/base-files/base-files/collie/fstab	2004-05-30 05:00:23.000000000 +1000
+++ b/base-files/base-files/collie/fstab	2004-06-01 15:20:37.000000000 +1000
 <at>  <at>  -1,5 +1,5  <at>  <at> 
 /dev/mtdblock4	/ 	jffs2	defaults	1  1 
+proc            /proc   proc    defaults        0  0
 /dev/hda1	/mnt/cf	auto	defaults,noauto,noatime,user,exec,suid	0  0
 /dev/mmcda1	/mnt/card	auto	defaults,noauto,noatime,user,exec,suid	0  0
 ramfs		/var	ramfs	defaults	0  0
-proc		/proc	proc	defaults	0  0
--- a/base-files/base-files/fstab	2004-05-30 05:00:23.000000000 +1000
+++ b/base-files/base-files/fstab	2004-06-01 15:17:37.000000000 +1000
 <at>  <at>  -1,4 +1,4  <at>  <at> 
+proc                 /proc                proc       defaults              0 0
 rootfs               /                    auto       defaults              1 1
 devpts               /dev/pts             devpts     mode=0620,gid=5       0 0
-proc                 /proc                proc       defaults              0 0

Question re "touchscreen" config on COLLIE

In the openzaurus-sa "defconfig-collie" the symbol 
"CONFIG_TOUCHSCREEN_UCB1200" is defined.  I didn't find code that 
referred to this symbol (other than a Makefile stem that added the 
ucb1200 driver to the "build" list.)  The symbol that controls the 
module compilation seems to be the "CONFIG_COLLIE_TS".  Is this a change 
that hasn't been quite finished?

If not, what is the path here.  Are the CONFIG_COLLIE symbols going away 
in favor of more generic ones?

-Gary

Re: bash completion for oe packages

Pretty cool. Just added that to OE/tools

Thanks.

Re: How to control library "Depends" versions info?

> Is there an easy way (short of doing the ipk creation "by hand") to
> control what specific versions of libraries get specifed on the Depends:
> line of the control file?  For example, I'm creating an app/applet
> bundle that needs libqpe1 but doesn't need the *specific* version being
> compiled in OE at the moment.  In fact it would be quite happy with the
> last OZ version as that's where I started writing the application.
> 
> Is there a way to make the package have a more "generic" version (or a
> specific one for that matter) so my package could work on a previous
> version of OZ/OE?
> 
> Right now, it looks like every few days a new version of stuff comes
> down the pike (I consider that a "good thing") but in order to install
> my ipk (without "forcing") I must recompile it afresh for each new cvs
> version of the library.
> 
> I've studied the package_ipk mechanism and haven't seen a place to do
> what I need.  Suggestions?

Good question. Phil, can we (you? :) add a VARIABLE to make shlibdeps
add only the name to Depends ?

--

-- 
Michael Lauer <mickey <at> tm.informatik.uni-frankfurt.de>
Institute of Telematics, CS. Dept., Frankfurt University

Re: What is the current TODO for Zaurus?

Am So, den 30.05.2004 um 21:58 Uhr -0700 schrieb Gary Oliver:
[...]
>  From personal experience (trying to build an opie-image) with the 5500, 
> I see that there are a number of loose ends.  The .postrm and .postinst 
> files have some broken shell script.  There are missing modules in the 
> kernel compile and sometimes some complaints about "tainted" modules 
> during startup (missing "License.")  Also, after fixing up a lot of 
> things manually (ldconfig and font libs) qpe won't come up due to a 
> missing touch panel driver.

Yes, someone needs to debug that. It's a problem with our qte build.

> Can the developers articulate a list of the things needed to bring out a 
> 5500 (collie) release?

http://openembedded.org/oe_wiki/index.php/OzTODO3.5.1

Note that there's also
http://openembedded.org/oe_wiki/index.php/OzTODO3.6.0, but that one
seems far away :D

:M:
--

-- 
Michael Lauer <mickey <at> tm.informatik.uni-frankfurt.de>
Institute of Telematics, CS. Dept., Frankfurt University

Re: base-files/fstab, must mount proc before using auto

Am Di, den 01.06.2004 um 15:32 Uhr +1000 schrieb Glenn McGrath:
> Busybox's mount uses /proc/filesystems to determine a list of possible
> filesystem to try when mounting filesystems of type "auto"
> 
> Two of the fstab's specify a mount point of type "auto" prior to
> specifying the proc entry, this breaks "mount -a" behaviour.
> 
> The attached patch moves proc up above the "auto" entries so mount can
> get the filesystem list prior to the "auto" entry.
> 
> "mount -a" will work again for generic and collie

Great. Applied - thanks.

:M:

Re: Question re "touchscreen" config on COLLIE

Am Mo, den 31.05.2004 um 22:59 Uhr -0700 schrieb Gary Oliver:
> In the openzaurus-sa "defconfig-collie" the symbol 
> "CONFIG_TOUCHSCREEN_UCB1200" is defined.  I didn't find code that 
> referred to this symbol (other than a Makefile stem that added the 
> ucb1200 driver to the "build" list.)  The symbol that controls the 
> module compilation seems to be the "CONFIG_COLLIE_TS".  Is this a change 
> that hasn't been quite finished?
> 
> If not, what is the path here.  Are the CONFIG_COLLIE symbols going away 
> in favor of more generic ones?

Frankly... no idea. I have been using this .config since the first OZ
release with kernel 2.4.18, so it's definitly known as working.

Since the embedix kernel is flaky at best and 2.4 is hopefully going
away anyway, we shouldn't change anything in this config until we are  <at> 
2.6 or our sane alternative to the embedix kernel (2.4.21-cl).

:M:

Re: How to control library "Depends" versions info?

> > Is there an easy way (short of doing the ipk creation "by hand") to
> > control what specific versions of libraries get specifed on the Depends:
> > line of the control file?  For example, I'm creating an app/applet
> > bundle that needs libqpe1 but doesn't need the *specific* version being
> > compiled in OE at the moment.  In fact it would be quite happy with the
> > last OZ version as that's where I started writing the application.
> > 
> > Is there a way to make the package have a more "generic" version (or a
> > specific one for that matter) so my package could work on a previous
> > version of OZ/OE?
> 
> Good question. Phil, can we (you? :) add a VARIABLE to make shlibdeps
> add only the name to Depends ?

That would be possible, but dangerous.  In the general case, if you
compile against version V of a particular shared library, the resulting
binary will run properly with V and all future versions, but not
necessarily with older versions.  This is precisely the version
relationship that shlibdeps currently captures in the Depends line.

Relaxing shlibdeps to omit version information from Depends would make
it easier to install packages on older distros, but there is no
guarantee that the packages will actually _work_ under those
circumstances.  I think it's probably better to leave things as they
are, and let people use --force-depends if they want to try their luck.

> > Right now, it looks like every few days a new version of stuff comes
> > down the pike (I consider that a "good thing") but in order to install
> > my ipk (without "forcing") I must recompile it afresh for each new cvs
> > version of the library.

Re: [Openzaurus-users] oemake

Note: This mail is offtopic here. Better use oe <at> handhelds.org or
openzaurus-devel <at> lists.sf.net.

[glibc-cvs bailing out with ICE]

> any Idea ??

Seems gcc is buggy, submit a bug report to the gcc folks.
In the meantime, you can use 

CVSDATE_glibc = "20040525"
CVSDATE_glibc-initial = "20040525"

to continue working.

--

-- 
:M:
--------------------------------------------------------------------------
Dipl.-Inf. Michael 'Mickey' Lauer   mickey <at> tm.informatik.uni-frankfurt.de 
  Raum 10b - ++49 69 798 28358       Fachbereich Informatik und Biologie  
--------------------------------------------------------------------------

anoncvs moved

Those of you who are using the anoncvs mirror of the OE tree might have
noticed that the path to the repository has changed.  You now need to
use:

cvs -d :pserver:anoncvs <at> cvs.handhelds.org:/cvs co oe

If you have an existing working tree with uncommitted changes, you can
fix it to work with the new layout by running these two commands:

$ for i in `find . -name Root`; do sed 's:/home/pb/oe/cvs:/cvs:' <$i
>$i.new; mv $i.new $i; done
$ for i in `find . -name Repository`; do sed 's:^oe:oe/oe:' <$i >$i.new;
mv $i.new $i; done

p.