astlinux-devel Mailing List for AstLinux

Unfortunately, it's more complicated than what you've done...

You're combining stdout and stderr... and then reading that into grep.

What I was trying to achieve is to filter stderr separately.

For instance, if I do:

"make all" >/dev/null

then I'm expecting to see *only* what gets written to stderr.

With your change, we lose this ability.

-Philip


On 09/30/2009 02:37 PM, abe...@us... wrote:
> Revision: 3342
>           http://astlinux.svn.sourceforge.net/astlinux/?rev=3342&view=rev
> Author:   abelbeck
> Date:     2009-09-30 21:37:08 +0000 (Wed, 30 Sep 2009)
>
> Log Message:
> -----------
> Makefile cleanup.  Limit noise on stderr.  Squashfs filesystem is smaller if we remove ext2 filesystem before rebuilding it.
>
> Modified Paths:
> --------------
>     branches/0.7/target/ext2/ext2root.mk
>     branches/0.7/target/initrd/initrd.mk
>     branches/0.7/target/squashfs/squashfsroot.mk
>
> Property Changed:
> ----------------
>     branches/0.7/
>
>
> Property changes on: branches/0.7
> ___________________________________________________________________
> Modified: svn:mergeinfo
>    - /branches/lonnie:2791
> /trunk:3325,3329
>    + /branches/lonnie:2791
> /trunk:3325,3329,3341
>
> Modified: branches/0.7/target/ext2/ext2root.mk
> ===================================================================
> --- branches/0.7/target/ext2/ext2root.mk	2009-09-29 21:59:48 UTC (rev 3341)
> +++ branches/0.7/target/ext2/ext2root.mk	2009-09-30 21:37:08 UTC (rev 3342)
> @@ -87,6 +87,7 @@
>  endif
>  
>  $(EXT2_TARGET): | host-fakeroot makedevs genext2fs
> +	rm -f $(EXT2_TARGET)
>  	@find $(TARGET_DIR) -type f -perm +111 | xargs $(STRIP) 2>/dev/null || true;
>  	@rm -rf $(TARGET_DIR)/usr/man
>  	@rm -rf $(TARGET_DIR)/usr/share/man
> @@ -119,7 +120,7 @@
>  		"$(EXT2_OPTS) $(EXT2_BASE)" >> $(STAGING_DIR)/_fakeroot.$(notdir $(EXT2_TARGET))
>  endif
>  	chmod a+x $(STAGING_DIR)/_fakeroot.$(notdir $(EXT2_TARGET))
> -	$(STAGING_DIR)/usr/bin/fakeroot -- $(STAGING_DIR)/_fakeroot.$(notdir $(EXT2_TARGET))
> +	$(STAGING_DIR)/usr/bin/fakeroot -- $(STAGING_DIR)/_fakeroot.$(notdir $(EXT2_TARGET)) 2>&1 | grep -v ': Operation not permitted' 1>&2
>  	@rm -f $(STAGING_DIR)/_fakeroot.$(notdir $(EXT2_TARGET))
>  
>  ifneq ($(EXT2_ROOTFS_COMPRESSOR),)
>
> Modified: branches/0.7/target/initrd/initrd.mk
> ===================================================================
> --- branches/0.7/target/initrd/initrd.mk	2009-09-29 21:59:48 UTC (rev 3341)
> +++ branches/0.7/target/initrd/initrd.mk	2009-09-30 21:37:08 UTC (rev 3342)
> @@ -41,15 +41,11 @@
>  	@rm -rf $(INITRD_DIR)/usr/share/man
>  	@rm -rf $(INITRD_DIR)/usr/info
>  	-/sbin/ldconfig -r $(INITRD_DIR) 2>/dev/null
> -	# $(INSTALL) -D -m 644 $(TARGET_DIR)/lib/modules/$(LINUX_VERSION)/kernel/fs/exportfs/exportfs.ko \
> -	# $(INITRD_DIR)/lib/modules/00001_exportfs.ko
> -	# $(INSTALL) -D -m 644 $(TARGET_DIR)/lib/modules/$(LINUX_VERSION)/kernel/fs/unionfs/unionfs.ko \
> -	# $(INITRD_DIR)/lib/modules/00002_unionfs.ko
>  	# Use fakeroot to pretend all target binaries are owned by root
>  	-$(STAGING_DIR)/usr/bin/fakeroot \
>  		-i $(STAGING_DIR)/fakeroot.env \
>  		-s $(STAGING_DIR)/fakeroot.env -- \
> -		chown -R root:root $(INITRD_DIR)
> +		chown -R root:root $(INITRD_DIR) 2>&1 | grep -v ': Operation not permitted' 1>&2
>  	# Use fakeroot to make busybox setuid
>  	-$(STAGING_DIR)/usr/bin/fakeroot \
>  		-i $(STAGING_DIR)/fakeroot.env \
>
> Modified: branches/0.7/target/squashfs/squashfsroot.mk
> ===================================================================
> --- branches/0.7/target/squashfs/squashfsroot.mk	2009-09-29 21:59:48 UTC (rev 3341)
> +++ branches/0.7/target/squashfs/squashfsroot.mk	2009-09-30 21:37:08 UTC (rev 3342)
> @@ -97,7 +97,7 @@
>  		    "-noappend $(SQUASHFS_ENDIANNESS)" \
>  		>> $(STAGING_DIR)/_fakeroot.$(notdir $(SQUASHFS_TARGET))
>  	chmod a+x $(STAGING_DIR)/_fakeroot.$(notdir $(SQUASHFS_TARGET))
> -	$(STAGING_DIR)/usr/bin/fakeroot -- $(STAGING_DIR)/_fakeroot.$(notdir $(SQUASHFS_TARGET))
> +	$(STAGING_DIR)/usr/bin/fakeroot -- $(STAGING_DIR)/_fakeroot.$(notdir $(SQUASHFS_TARGET)) 2>&1 | grep -v ': Operation not permitted' 1>&2
>  	@rm -f $(STAGING_DIR)/_fakeroot.$(notdir $(SQUASHFS_TARGET))
>  
>  squashfsroot: $(SQUASHFS_TARGET)
>   

OK, I'll take a look at it.

Lonnie

On Sep 30, 2009, at 3:58 PM, Philip A. Prindeville wrote:

> I don't have time to deal with this today or tomorrow.
>
> What I was doing was getting the STDERR of "fakeroot" to be grepped  
> out
> for all lines not matching ": Operation not permitted" and then sent
> back onto STDERR.
>
> If you can get this working with "n>&..." and "n<&..." then please  
> do so.
>
>
> On 09/30/2009 05:47 AM, Lonnie Abelbeck wrote:
>> Philip,
>>
>> My bash does not support the  |&  control operator either.
>>
>> Will  2>&1 |  do the same thing as  |&  ?
>>
>> Lonnie
>>
>> On Sep 30, 2009, at 3:47 AM, Michael Keuter wrote:
>>
>>
>>> Hi Philip,
>>>
>>> with your commit in 3341 I got these error while building:
>>>
>>> ...
>>> ...
>>> chmod a+x
>>> /home/mk/source-control/astlinux-trunk/build_i586/staging_dir/
>>> _fakeroot.rootfs.i586.ext2
>>> /home/mk/source-control/astlinux-trunk/build_i586/staging_dir/usr/
>>> bin/fakeroot
>>> -- 
>>> /home/mk/source-control/astlinux-trunk/build_i586/staging_dir/
>>> _fakeroot.rootfs.i586.ext2
>>> |& grep -v ': Operation not permitted' 1>&2
>>> /bin/sh: -c: line 0: syntax error near unexpected token `&'
>>> /bin/sh: -c: line 0:
>>> `/home/mk/source-control/astlinux-trunk/build_i586/staging_dir/usr/
>>> bin/fakeroot
>>> -- 
>>> /home/mk/source-control/astlinux-trunk/build_i586/staging_dir/
>>> _fakeroot.rootfs.i586.ext2
>>> |& grep -v ': Operation not permitted' 1>&2'
>>> make: *** [/home/mk/source-control/astlinux-trunk/rootfs.i586.ext2]
>>> Error 2
>>> Script done, file is build.log_
>>>
>>> Michael
>>>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register  
> now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr... 
> .
>
>

I don't have time to deal with this today or tomorrow.

What I was doing was getting the STDERR of "fakeroot" to be grepped out
for all lines not matching ": Operation not permitted" and then sent
back onto STDERR.

If you can get this working with "n>&..." and "n<&..." then please do so.


On 09/30/2009 05:47 AM, Lonnie Abelbeck wrote:
> Philip,
>
> My bash does not support the  |&  control operator either.
>
> Will  2>&1 |  do the same thing as  |&  ?
>
> Lonnie
>
> On Sep 30, 2009, at 3:47 AM, Michael Keuter wrote:
>
>   
>> Hi Philip,
>>
>> with your commit in 3341 I got these error while building:
>>
>> ...
>> ...
>> chmod a+x
>> /home/mk/source-control/astlinux-trunk/build_i586/staging_dir/ 
>> _fakeroot.rootfs.i586.ext2
>> /home/mk/source-control/astlinux-trunk/build_i586/staging_dir/usr/ 
>> bin/fakeroot
>> -- 
>> /home/mk/source-control/astlinux-trunk/build_i586/staging_dir/ 
>> _fakeroot.rootfs.i586.ext2
>> |& grep -v ': Operation not permitted' 1>&2
>> /bin/sh: -c: line 0: syntax error near unexpected token `&'
>> /bin/sh: -c: line 0:
>> `/home/mk/source-control/astlinux-trunk/build_i586/staging_dir/usr/ 
>> bin/fakeroot
>> -- 
>> /home/mk/source-control/astlinux-trunk/build_i586/staging_dir/ 
>> _fakeroot.rootfs.i586.ext2
>> |& grep -v ': Operation not permitted' 1>&2'
>> make: *** [/home/mk/source-control/astlinux-trunk/rootfs.i586.ext2]  
>> Error 2
>> Script done, file is build.log_
>>
>> Michael
>>     

Philip,

My bash does not support the  |&  control operator either.

Will  2>&1 |  do the same thing as  |&  ?

Lonnie

On Sep 30, 2009, at 3:47 AM, Michael Keuter wrote:

> Hi Philip,
>
> with your commit in 3341 I got these error while building:
>
> ...
> ...
> chmod a+x
> /home/mk/source-control/astlinux-trunk/build_i586/staging_dir/ 
> _fakeroot.rootfs.i586.ext2
> /home/mk/source-control/astlinux-trunk/build_i586/staging_dir/usr/ 
> bin/fakeroot
> -- 
> /home/mk/source-control/astlinux-trunk/build_i586/staging_dir/ 
> _fakeroot.rootfs.i586.ext2
> |& grep -v ': Operation not permitted' 1>&2
> /bin/sh: -c: line 0: syntax error near unexpected token `&'
> /bin/sh: -c: line 0:
> `/home/mk/source-control/astlinux-trunk/build_i586/staging_dir/usr/ 
> bin/fakeroot
> -- 
> /home/mk/source-control/astlinux-trunk/build_i586/staging_dir/ 
> _fakeroot.rootfs.i586.ext2
> |& grep -v ': Operation not permitted' 1>&2'
> make: *** [/home/mk/source-control/astlinux-trunk/rootfs.i586.ext2]  
> Error 2
> Script done, file is build.log_
>
> Michael

>Recent trunk and 0.7 builds have grown considerably over the 0.6 release
>sizes.  In an effort to minimize this growth, we're looking at several
>areas.  My understanding is the wancfg utility really doesn't function
>on Astlinux due to missing perl dependencies (that we won't be
>fulfilling).
>
>Can we get some clarification on which files can go and which files must
>stay from the /stat/etc/wanpipe directory?  My understanding is the
>config file must be generated manually.
>
>Thanks,
>
>Darrick

Hi Darrick,

I attached a "/etc/wanpipe" directory listing from a Debian Lenny 
installation with a Sangoma  B700 card.

Michael

Hi Philip,

with your commit in 3341 I got these error while building:

...
...
chmod a+x 
/home/mk/source-control/astlinux-trunk/build_i586/staging_dir/_fakeroot.rootfs.i586.ext2
/home/mk/source-control/astlinux-trunk/build_i586/staging_dir/usr/bin/fakeroot 
-- 
/home/mk/source-control/astlinux-trunk/build_i586/staging_dir/_fakeroot.rootfs.i586.ext2 
|& grep -v ': Operation not permitted' 1>&2
/bin/sh: -c: line 0: syntax error near unexpected token `&'
/bin/sh: -c: line 0: 
`/home/mk/source-control/astlinux-trunk/build_i586/staging_dir/usr/bin/fakeroot 
-- 
/home/mk/source-control/astlinux-trunk/build_i586/staging_dir/_fakeroot.rootfs.i586.ext2 
|& grep -v ': Operation not permitted' 1>&2'
make: *** [/home/mk/source-control/astlinux-trunk/rootfs.i586.ext2] Error 2
Script done, file is build.log_

Michael

Recent trunk and 0.7 builds have grown considerably over the 0.6 release 
sizes.  In an effort to minimize this growth, we're looking at several 
areas.  My understanding is the wancfg utility really doesn't function 
on Astlinux due to missing perl dependencies (that we won't be 
fulfilling).

Can we get some clarification on which files can go and which files must 
stay from the /stat/etc/wanpipe directory?  My understanding is the 
config file must be generated manually.

Thanks,

Darrick

Ahhh, so this is a generic problem.

Looks like Philip fixed this issue with trunk-3341

Thanks...

Lonnie

On Sep 29, 2009, at 6:33 PM, David Kerr wrote:

> No, I've promoted Ubuntu 64-bit to run native on a Core 2 Duo  
> system... other platforms (from a certain company from the northwest  
> usa) demoted to VMware guests.
>
> David
>
> On Tue, Sep 29, 2009 at 5:25 PM, Lonnie Abelbeck <li...@lo... 
> > wrote:
> David,
>
> Exactly what I'm seeing.
>
> Are you also using VMware for your build environment?
>
> Lonnie
>
>
>
> On Sep 29, 2009, at 3:59 PM, David Kerr wrote:
>
> I can confirm that I am seeing the same behavior.
>
> In the 0.7 branch svn 3332 and 3340, with my particular package  
> selection for Alix target...
> The .run file is 30.3MB in size starting from a completely clean  
> build tree.  If I then rebuild by deleting build_i586 directory, but  
> leaving the rootfs.i586.* files, then the .run file is 32.6MB.  If I  
> then rebuild by deleting the build_i586 AND the rootfs.i586.* files  
> then the resulting .run file is 30.3MB again.
>
> Something is going on, so I'll now get into the habit of erasing the  
> rootfs.i586.* files as well now.
>
> David
>
> On Mon, Sep 28, 2009 at 6:57 PM, Lonnie Abelbeck <li...@lo... 
> > wrote:
> Interesting...
>
> With that in mind, I'm using a rather small VMware partition, this
> might be unique to my setup.
>
> But if this is a general observation of others, then this fix might be
> added to the default build script.
>
> Lonnie
>
>
> On Sep 28, 2009, at 5:44 PM, Philip A. Prindeville wrote:
>
> > It could be related to fragmentation, and a freelist of blocks being
> > left behind after doing various cleanup such as "rm -rf
> > $(TARGET_DIR)/usr/man ..." etc.
> >
> >
> > On 09/28/2009 02:59 PM, Lonnie Abelbeck wrote:
> >> While building new images I was reminded of an old issue.
> >>
> >> Basically, if I 'svn co'  to a fresh directory and build, I get
> >> a .run
> >> image of 'x' MB's.
> >>
> >> Then, I make a couple very minor changes, make a package outside of
> >> 'make menuconfig', make a new clean build,  I get a .run image of  
> 'x'
> >> + 2.4 MB's.
> >>
> >> The solution is to "rm -f rootfs.i586.*" before 'make all runfs' in
> >> the build script.
> >>
> >> It appears that if the previous rootfs* files are not removed any
> >> previous extra size is maintained.
> >>
> >> Does this make sense?
> >>
> >> Lonnie
> >>
> >
> >
> >  
> ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry&reg; Developer Conference in  
> SF, CA
> > is the only developer event you need to attend this year. Jumpstart
> > your
> > developing skills, take BlackBerry mobile applications to market and
> > stay
> > ahead of the curve. Join us from November 9&#45;12, 2009. Register
> > now&#33;
> > http://p.sf.net/sfu/devconf
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal  
> to pa...@kr...
> > .
> >
> >
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register  
> now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr... 
> .
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register  
> now&#33;
> http://p.sf.net/sfu/devconf_______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr... 
> .
>
>

No, I've promoted Ubuntu 64-bit to run native on a Core 2 Duo system...
other platforms (from a certain company from the northwest usa) demoted to
VMware guests.
David

On Tue, Sep 29, 2009 at 5:25 PM, Lonnie Abelbeck
<li...@lo...>wrote:

> David,
>
> Exactly what I'm seeing.
>
> Are you also using VMware for your build environment?
>
> Lonnie
>
>
>
> On Sep 29, 2009, at 3:59 PM, David Kerr wrote:
>
>  I can confirm that I am seeing the same behavior.
>>
>> In the 0.7 branch svn 3332 and 3340, with my particular package selection
>> for Alix target...
>> The .run file is 30.3MB in size starting from a completely clean build
>> tree.  If I then rebuild by deleting build_i586 directory, but leaving the
>> rootfs.i586.* files, then the .run file is 32.6MB.  If I then rebuild by
>> deleting the build_i586 AND the rootfs.i586.* files then the resulting .run
>> file is 30.3MB again.
>>
>> Something is going on, so I'll now get into the habit of erasing the
>> rootfs.i586.* files as well now.
>>
>> David
>>
>> On Mon, Sep 28, 2009 at 6:57 PM, Lonnie Abelbeck <
>> li...@lo...> wrote:
>> Interesting...
>>
>> With that in mind, I'm using a rather small VMware partition, this
>> might be unique to my setup.
>>
>> But if this is a general observation of others, then this fix might be
>> added to the default build script.
>>
>> Lonnie
>>
>>
>> On Sep 28, 2009, at 5:44 PM, Philip A. Prindeville wrote:
>>
>> > It could be related to fragmentation, and a freelist of blocks being
>> > left behind after doing various cleanup such as "rm -rf
>> > $(TARGET_DIR)/usr/man ..." etc.
>> >
>> >
>> > On 09/28/2009 02:59 PM, Lonnie Abelbeck wrote:
>> >> While building new images I was reminded of an old issue.
>> >>
>> >> Basically, if I 'svn co'  to a fresh directory and build, I get
>> >> a .run
>> >> image of 'x' MB's.
>> >>
>> >> Then, I make a couple very minor changes, make a package outside of
>> >> 'make menuconfig', make a new clean build,  I get a .run image of 'x'
>> >> + 2.4 MB's.
>> >>
>> >> The solution is to "rm -f rootfs.i586.*" before 'make all runfs' in
>> >> the build script.
>> >>
>> >> It appears that if the previous rootfs* files are not removed any
>> >> previous extra size is maintained.
>> >>
>> >> Does this make sense?
>> >>
>> >> Lonnie
>> >>
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>> > is the only developer event you need to attend this year. Jumpstart
>> > your
>> > developing skills, take BlackBerry mobile applications to market and
>> > stay
>> > ahead of the curve. Join us from November 9&#45;12, 2009. Register
>> > now&#33;
>> > http://p.sf.net/sfu/devconf
>> > _______________________________________________
>> > Astlinux-devel mailing list
>> > Ast...@li...
>> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>> >
>> > Donations to support AstLinux are graciously accepted via PayPal to
>> pa...@kr...
>> > .
>> >
>> >
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9&#45;12, 2009. Register
>> now&#33;
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>
>> Donations to support AstLinux are graciously accepted via PayPal to
>> pa...@kr....
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9&#45;12, 2009. Register
>> now&#33;
>> http://p.sf.net/sfu/devconf_______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>
>> Donations to support AstLinux are graciously accepted via PayPal to
>> pa...@kr....
>>
>
>

David,

Exactly what I'm seeing.

Are you also using VMware for your build environment?

Lonnie


On Sep 29, 2009, at 3:59 PM, David Kerr wrote:

> I can confirm that I am seeing the same behavior.
>
> In the 0.7 branch svn 3332 and 3340, with my particular package  
> selection for Alix target...
> The .run file is 30.3MB in size starting from a completely clean  
> build tree.  If I then rebuild by deleting build_i586 directory, but  
> leaving the rootfs.i586.* files, then the .run file is 32.6MB.  If I  
> then rebuild by deleting the build_i586 AND the rootfs.i586.* files  
> then the resulting .run file is 30.3MB again.
>
> Something is going on, so I'll now get into the habit of erasing the  
> rootfs.i586.* files as well now.
>
> David
>
> On Mon, Sep 28, 2009 at 6:57 PM, Lonnie Abelbeck <li...@lo... 
> > wrote:
> Interesting...
>
> With that in mind, I'm using a rather small VMware partition, this
> might be unique to my setup.
>
> But if this is a general observation of others, then this fix might be
> added to the default build script.
>
> Lonnie
>
>
> On Sep 28, 2009, at 5:44 PM, Philip A. Prindeville wrote:
>
> > It could be related to fragmentation, and a freelist of blocks being
> > left behind after doing various cleanup such as "rm -rf
> > $(TARGET_DIR)/usr/man ..." etc.
> >
> >
> > On 09/28/2009 02:59 PM, Lonnie Abelbeck wrote:
> >> While building new images I was reminded of an old issue.
> >>
> >> Basically, if I 'svn co'  to a fresh directory and build, I get
> >> a .run
> >> image of 'x' MB's.
> >>
> >> Then, I make a couple very minor changes, make a package outside of
> >> 'make menuconfig', make a new clean build,  I get a .run image of  
> 'x'
> >> + 2.4 MB's.
> >>
> >> The solution is to "rm -f rootfs.i586.*" before 'make all runfs' in
> >> the build script.
> >>
> >> It appears that if the previous rootfs* files are not removed any
> >> previous extra size is maintained.
> >>
> >> Does this make sense?
> >>
> >> Lonnie
> >>
> >
> >
> >  
> ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry&reg; Developer Conference in  
> SF, CA
> > is the only developer event you need to attend this year. Jumpstart
> > your
> > developing skills, take BlackBerry mobile applications to market and
> > stay
> > ahead of the curve. Join us from November 9&#45;12, 2009. Register
> > now&#33;
> > http://p.sf.net/sfu/devconf
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal  
> to pa...@kr...
> > .
> >
> >
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register  
> now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr... 
> .
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register  
> now&#33;
> http://p.sf.net/sfu/devconf_______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr... 
> .

I can confirm that I am seeing the same behavior.
In the 0.7 branch svn 3332 and 3340, with my particular package selection
for Alix target...
The .run file is 30.3MB in size starting from a completely clean build tree.
 If I then rebuild by deleting build_i586 directory, but leaving the
rootfs.i586.* files, then the .run file is 32.6MB.  If I then rebuild by
deleting the build_i586 AND the rootfs.i586.* files then the resulting .run
file is 30.3MB again.
Something is going on, so I'll now get into the habit of erasing the
rootfs.i586.* files as well now.

David

On Mon, Sep 28, 2009 at 6:57 PM, Lonnie Abelbeck
<li...@lo...>wrote:

> Interesting...
>
> With that in mind, I'm using a rather small VMware partition, this
> might be unique to my setup.
>
> But if this is a general observation of others, then this fix might be
> added to the default build script.
>
> Lonnie
>
>
> On Sep 28, 2009, at 5:44 PM, Philip A. Prindeville wrote:
>
> > It could be related to fragmentation, and a freelist of blocks being
> > left behind after doing various cleanup such as "rm -rf
> > $(TARGET_DIR)/usr/man ..." etc.
> >
> >
> > On 09/28/2009 02:59 PM, Lonnie Abelbeck wrote:
> >> While building new images I was reminded of an old issue.
> >>
> >> Basically, if I 'svn co'  to a fresh directory and build, I get
> >> a .run
> >> image of 'x' MB's.
> >>
> >> Then, I make a couple very minor changes, make a package outside of
> >> 'make menuconfig', make a new clean build,  I get a .run image of 'x'
> >> + 2.4 MB's.
> >>
> >> The solution is to "rm -f rootfs.i586.*" before 'make all runfs' in
> >> the build script.
> >>
> >> It appears that if the previous rootfs* files are not removed any
> >> previous extra size is maintained.
> >>
> >> Does this make sense?
> >>
> >> Lonnie
> >>
> >
> >
> >
> ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart
> > your
> > developing skills, take BlackBerry mobile applications to market and
> > stay
> > ahead of the curve. Join us from November 9&#45;12, 2009. Register
> > now&#33;
> > http://p.sf.net/sfu/devconf
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr...
> > .
> >
> >
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>

Interesting...

With that in mind, I'm using a rather small VMware partition, this  
might be unique to my setup.

But if this is a general observation of others, then this fix might be  
added to the default build script.

Lonnie


On Sep 28, 2009, at 5:44 PM, Philip A. Prindeville wrote:

> It could be related to fragmentation, and a freelist of blocks being
> left behind after doing various cleanup such as "rm -rf
> $(TARGET_DIR)/usr/man ..." etc.
>
>
> On 09/28/2009 02:59 PM, Lonnie Abelbeck wrote:
>> While building new images I was reminded of an old issue.
>>
>> Basically, if I 'svn co'  to a fresh directory and build, I get  
>> a .run
>> image of 'x' MB's.
>>
>> Then, I make a couple very minor changes, make a package outside of
>> 'make menuconfig', make a new clean build,  I get a .run image of 'x'
>> + 2.4 MB's.
>>
>> The solution is to "rm -f rootfs.i586.*" before 'make all runfs' in
>> the build script.
>>
>> It appears that if the previous rootfs* files are not removed any
>> previous extra size is maintained.
>>
>> Does this make sense?
>>
>> Lonnie
>>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register  
> now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr... 
> .
>
>

It could be related to fragmentation, and a freelist of blocks being
left behind after doing various cleanup such as "rm -rf
$(TARGET_DIR)/usr/man ..." etc.


On 09/28/2009 02:59 PM, Lonnie Abelbeck wrote:
> While building new images I was reminded of an old issue.
>
> Basically, if I 'svn co'  to a fresh directory and build, I get a .run  
> image of 'x' MB's.
>
> Then, I make a couple very minor changes, make a package outside of  
> 'make menuconfig', make a new clean build,  I get a .run image of 'x'  
> + 2.4 MB's.
>
> The solution is to "rm -f rootfs.i586.*" before 'make all runfs' in  
> the build script.
>
> It appears that if the previous rootfs* files are not removed any  
> previous extra size is maintained.
>
> Does this make sense?
>
> Lonnie
>   

While building new images I was reminded of an old issue.

Basically, if I 'svn co'  to a fresh directory and build, I get a .run  
image of 'x' MB's.

Then, I make a couple very minor changes, make a package outside of  
'make menuconfig', make a new clean build,  I get a .run image of 'x'  
+ 2.4 MB's.

The solution is to "rm -f rootfs.i586.*" before 'make all runfs' in  
the build script.

It appears that if the previous rootfs* files are not removed any  
previous extra size is maintained.

Does this make sense?

Lonnie

Philip,

I'll take a look at this tomorrow.

Philip A. Prindeville wrote:
> So to be crystal clear, I've attached the diffs that *should have been
> applied* to take you back to libusb-0.1
> 
> Other than labelling my commits clearly as below, I don't know what else
> I should be doing:
> 
>> Revision: 3319
>>           http://astlinux.svn.sourceforge.net/astlinux/?rev=3319&view=rev
>> Author:   pprindeville
>> Date:     2009-09-16 19:07:16 +0000 (Wed, 16 Sep 2009)
>>
>> Log Message:
>> -----------
>> Fix broken targets and intermediate targets. Other makefile cleanup.
>>   
> 
> "Fix broken targets and intermediate targets" should make it pretty
> clear that this wasn't part of the libusb version bump.
> 
> Please apply the attached patches.
> 
> 
> 
> On 09/26/2009 01:26 PM, Philip A. Prindeville wrote:
>> Um, yeah, 3327.
>>
>> And not ALL of 3327 was related to libusb-1.0, as you seem to be asserting.
>>
>>
>> On 09/25/2009 02:39 PM, Darrick Hartman wrote:
>>   
>>> Do you have a specific commit in mind?  All of the libusb-1.0 related 
>>> changes were required to go.  We're not using libusb-1.0.  If there are 
>>> changes which contribute positively towards a stable release, I'd be all 
>>> ears for knowing which lines should go back in.
>>>
>>> Philip A. Prindeville wrote:
>>>   
>>>     
>>>> Ok, so that accounts for one line... What about all of the rest of the
>>>> changes that were needlessly backed out?
>>>>
>>>>
>>>> On 09/25/2009 02:01 PM, Darrick Hartman wrote:
>>>>     
>>>>       
>>>>> Philip,
>>>>>
>>>>> usbutils has been built this way (without using zlib) for a very long 
>>>>> time (all of 0.6 for sure, probably longer).  If we don't link against 
>>>>> zlib, the .gz file is never created.  Granted, in 0.6 with did not 
>>>>> explicitly state --without-zlib, but that's because the order of 
>>>>> compilation was fixed in trunk.
>>>>>
>>>>> pciutils works the same way.  All I know is if usbutils and pciutils are 
>>>>> linked against zlib, that both lspci and lsusb take about 30-40 seconds 
>>>>> on more limited hardware.
>>>>>
>>>>>
>>>>>
>>>>> Philip A. Prindeville wrote:
>>>>>   
>>>>>       
>>>>>         
>>>>>> You know what? You want to gratuitously diverge the branch from trunk,
>>>>>> that's your call.
>>>>>>
>>>>>> I don't recommend it.
>>>>>>
>>>>>> Deleting the usb.ids.gz file saves room in the ramfs, which as you
>>>>>> remember you said yesterday was getting crowded...
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 09/25/2009 01:20 PM, Darrick Hartman wrote:
>>>>>>     
>>>>>>         
>>>>>>           
>>>>>>> Philip,
>>>>>>>
>>>>>>> What items won't build properly with the way 0.7 is right now?  Neither 
>>>>>>> Lonnie or I are seeing any breakage with the current status.
>>>>>>>
>>>>>>> What does compiling against zlib get us if we're not using the generated 
>>>>>>> file?  My understanding is that not linking against zlib or deleting the 
>>>>>>> usb.ids.gz file results in the same outcome.  If that's not correct, 
>>>>>>> please clarify.
>>>>>>>
>>>>>>> Philip A. Prindeville wrote:
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>             
>>>>>>>> So, can you make the necessary reversions please?
>>>>>>>>
>>>>>>>> -Philip
>>>>>>>>
>>>>>>>>
>>>>>>>> On 09/24/2009 11:42 AM, Philip A. Prindeville wrote:
>>>>>>>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>>>               
>>>>>>>>> Since you didn't ask before making the changes, I figured you had that
>>>>>>>>> all worked out...
>>>>>>>>>
>>>>>>>>> Guess not.
>>>>>>>>>
>>>>>>>>> All you *really* needed to do, was switch "libusb-compat" back to
>>>>>>>>> "libusb" as a dependency, change "libusb-1.0" into "libusb" (or
>>>>>>>>> "-lusb-1.0" into "-lusb") wherever you saw that as a linker flag,
>>>>>>>>> disable BR2_PACKAGE_LIBUSB-COMPAT, and revert the version # and URL in
>>>>>>>>> package/libusb/libusb.mk (maybe also the setting for LIBUSB_CAT).
>>>>>>>>>
>>>>>>>>> That was it.
>>>>>>>>>
>>>>>>>>> The patch to libusb-config for instance is not needed, and should have
>>>>>>>>> been left out. And the extra flags being passed into Make, the shuffling
>>>>>>>>> of files, etc. was totally unnecessary and just confuses the issue.
>>>>>>>>>
>>>>>>>>> The patch to usbutils's makefile is correct, and fixes a bug... as well
>>>>>>>>> as being benign with earlier versions.
>>>>>>>>>
>>>>>>>>> And the fix leaving the linkage with zlib, but removing the usb.ids.gz
>>>>>>>>> file is the correct one: what install a file you're unequipped to read?
>>>>>>>>> That just wastes space...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 09/24/2009 05:11 AM, Lonnie Abelbeck wrote:
>>>>>>>>>   
>>>>>>>>>       
>>>>>>>>>           
>>>>>>>>>               
>>>>>>>>>                 
>>>>>>>>>> Philip,
>>>>>>>>>>
>>>>>>>>>> I reverted usb to trunk-3312 in 0.7.
>>>>>>>>>>
>>>>>>>>>> The resulting 0.7 build appears to work properly.
>>>>>>>>>>
>>>>>>>>>> If you have any specific cleanups that were a part of your usb-compat  
>>>>>>>>>> changes I'm all ears.
>>>>>>>>>>
>>>>>>>>>> Lonnie
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sep 23, 2009, at 8:02 PM, Philip A. Prindeville wrote:
>>>>>>>>>>
>>>>>>>>>>   
>>>>>>>>>>     
>>>>>>>>>>         
>>>>>>>>>>             
>>>>>>>>>>                 
>>>>>>>>>>                   
>>>>>>>>>>> Some of what you're backing out is actually needed cleanup to broken
>>>>>>>>>>> makefiles.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 09/23/2009 05:16 PM, abe...@us... wrote:
>>>>>>>>>>>     
>>>>>>>>>>>       
>>>>>>>>>>>           
>>>>>>>>>>>               
>>>>>>>>>>>                   
>>>>>>>>>>>                     
>>>>>>>>>>>> Revision: 3327
>>>>>>>>>>>>          http://astlinux.svn.sourceforge.net/astlinux/?rev=3327&view=rev
>>>>>>>>>>>> Author:   abelbeck
>>>>>>>>>>>> Date:     2009-09-24 00:16:45 +0000 (Thu, 24 Sep 2009)
>>>>>>>>>>>>
>>>>>>>>>>>> Log Message:
>>>>>>>>>>>> -----------
>>>>>>>>>>>> Remove libusb-compat from 0.7 branch
>>>>>>>>>>>>
>>>>>>>>>>>> Modified Paths:
>>>>>>>>>>>> --------------
>>>>>>>>>>>>    branches/0.7/astlinux.config
>>>>>>>>>>>>    branches/0.7/package/Config.in
>>>>>>>>>>>>    branches/0.7/package/apcupsd/apcupsd.mk
>>>>>>>>>>>>    branches/0.7/package/dahdi-linux/dahdi-linux.mk
>>>>>>>>>>>>    branches/0.7/package/dahdi-tools/dahdi-tools.mk
>>>>>>>>>>>>    branches/0.7/package/lcdproc/lcdproc.mk
>>>>>>>>>>>>    branches/0.7/package/libftdi/libftdi.mk
>>>>>>>>>>>>    branches/0.7/package/libusb/libusb.mk
>>>>>>>>>>>>    branches/0.7/package/usbutils/usbutils.mk
>>>>>>>>>>>>    branches/0.7/package/zaptel/zaptel.mk
>>>>>>>>>>>>
>>>>>>>>>>>> Added Paths:
>>>>>>>>>>>> -----------
>>>>>>>>>>>>    branches/0.7/package/libusb/libusb-config
>>>>>>>>>>>>
>>>>>>>>>>>> Removed Paths:
>>>>>>>>>>>> -------------
>>>>>>>>>>>>    branches/0.7/package/libusb-compat/
>>>>>>>>>>>>    branches/0.7/package/usbutils/usbutils-makefile.patch
>>>>>>>>>>>>             
>>>>>>>>>>>>                 
>>>>>>>>>>>>                     
>>>>>>>>>>>>                       
>>>>       
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

So to be crystal clear, I've attached the diffs that *should have been
applied* to take you back to libusb-0.1

Other than labelling my commits clearly as below, I don't know what else
I should be doing:

> Revision: 3319
>           http://astlinux.svn.sourceforge.net/astlinux/?rev=3319&view=rev
> Author:   pprindeville
> Date:     2009-09-16 19:07:16 +0000 (Wed, 16 Sep 2009)
>
> Log Message:
> -----------
> Fix broken targets and intermediate targets. Other makefile cleanup.
>   

"Fix broken targets and intermediate targets" should make it pretty
clear that this wasn't part of the libusb version bump.

Please apply the attached patches.



On 09/26/2009 01:26 PM, Philip A. Prindeville wrote:
> Um, yeah, 3327.
>
> And not ALL of 3327 was related to libusb-1.0, as you seem to be asserting.
>
>
> On 09/25/2009 02:39 PM, Darrick Hartman wrote:
>   
>> Do you have a specific commit in mind?  All of the libusb-1.0 related 
>> changes were required to go.  We're not using libusb-1.0.  If there are 
>> changes which contribute positively towards a stable release, I'd be all 
>> ears for knowing which lines should go back in.
>>
>> Philip A. Prindeville wrote:
>>   
>>     
>>> Ok, so that accounts for one line... What about all of the rest of the
>>> changes that were needlessly backed out?
>>>
>>>
>>> On 09/25/2009 02:01 PM, Darrick Hartman wrote:
>>>     
>>>       
>>>> Philip,
>>>>
>>>> usbutils has been built this way (without using zlib) for a very long 
>>>> time (all of 0.6 for sure, probably longer).  If we don't link against 
>>>> zlib, the .gz file is never created.  Granted, in 0.6 with did not 
>>>> explicitly state --without-zlib, but that's because the order of 
>>>> compilation was fixed in trunk.
>>>>
>>>> pciutils works the same way.  All I know is if usbutils and pciutils are 
>>>> linked against zlib, that both lspci and lsusb take about 30-40 seconds 
>>>> on more limited hardware.
>>>>
>>>>
>>>>
>>>> Philip A. Prindeville wrote:
>>>>   
>>>>       
>>>>         
>>>>> You know what? You want to gratuitously diverge the branch from trunk,
>>>>> that's your call.
>>>>>
>>>>> I don't recommend it.
>>>>>
>>>>> Deleting the usb.ids.gz file saves room in the ramfs, which as you
>>>>> remember you said yesterday was getting crowded...
>>>>>
>>>>>
>>>>>
>>>>> On 09/25/2009 01:20 PM, Darrick Hartman wrote:
>>>>>     
>>>>>         
>>>>>           
>>>>>> Philip,
>>>>>>
>>>>>> What items won't build properly with the way 0.7 is right now?  Neither 
>>>>>> Lonnie or I are seeing any breakage with the current status.
>>>>>>
>>>>>> What does compiling against zlib get us if we're not using the generated 
>>>>>> file?  My understanding is that not linking against zlib or deleting the 
>>>>>> usb.ids.gz file results in the same outcome.  If that's not correct, 
>>>>>> please clarify.
>>>>>>
>>>>>> Philip A. Prindeville wrote:
>>>>>>   
>>>>>>       
>>>>>>           
>>>>>>             
>>>>>>> So, can you make the necessary reversions please?
>>>>>>>
>>>>>>> -Philip
>>>>>>>
>>>>>>>
>>>>>>> On 09/24/2009 11:42 AM, Philip A. Prindeville wrote:
>>>>>>>     
>>>>>>>         
>>>>>>>             
>>>>>>>               
>>>>>>>> Since you didn't ask before making the changes, I figured you had that
>>>>>>>> all worked out...
>>>>>>>>
>>>>>>>> Guess not.
>>>>>>>>
>>>>>>>> All you *really* needed to do, was switch "libusb-compat" back to
>>>>>>>> "libusb" as a dependency, change "libusb-1.0" into "libusb" (or
>>>>>>>> "-lusb-1.0" into "-lusb") wherever you saw that as a linker flag,
>>>>>>>> disable BR2_PACKAGE_LIBUSB-COMPAT, and revert the version # and URL in
>>>>>>>> package/libusb/libusb.mk (maybe also the setting for LIBUSB_CAT).
>>>>>>>>
>>>>>>>> That was it.
>>>>>>>>
>>>>>>>> The patch to libusb-config for instance is not needed, and should have
>>>>>>>> been left out. And the extra flags being passed into Make, the shuffling
>>>>>>>> of files, etc. was totally unnecessary and just confuses the issue.
>>>>>>>>
>>>>>>>> The patch to usbutils's makefile is correct, and fixes a bug... as well
>>>>>>>> as being benign with earlier versions.
>>>>>>>>
>>>>>>>> And the fix leaving the linkage with zlib, but removing the usb.ids.gz
>>>>>>>> file is the correct one: what install a file you're unequipped to read?
>>>>>>>> That just wastes space...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 09/24/2009 05:11 AM, Lonnie Abelbeck wrote:
>>>>>>>>   
>>>>>>>>       
>>>>>>>>           
>>>>>>>>               
>>>>>>>>                 
>>>>>>>>> Philip,
>>>>>>>>>
>>>>>>>>> I reverted usb to trunk-3312 in 0.7.
>>>>>>>>>
>>>>>>>>> The resulting 0.7 build appears to work properly.
>>>>>>>>>
>>>>>>>>> If you have any specific cleanups that were a part of your usb-compat  
>>>>>>>>> changes I'm all ears.
>>>>>>>>>
>>>>>>>>> Lonnie
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sep 23, 2009, at 8:02 PM, Philip A. Prindeville wrote:
>>>>>>>>>
>>>>>>>>>   
>>>>>>>>>     
>>>>>>>>>         
>>>>>>>>>             
>>>>>>>>>                 
>>>>>>>>>                   
>>>>>>>>>> Some of what you're backing out is actually needed cleanup to broken
>>>>>>>>>> makefiles.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 09/23/2009 05:16 PM, abe...@us... wrote:
>>>>>>>>>>     
>>>>>>>>>>       
>>>>>>>>>>           
>>>>>>>>>>               
>>>>>>>>>>                   
>>>>>>>>>>                     
>>>>>>>>>>> Revision: 3327
>>>>>>>>>>>          http://astlinux.svn.sourceforge.net/astlinux/?rev=3327&view=rev
>>>>>>>>>>> Author:   abelbeck
>>>>>>>>>>> Date:     2009-09-24 00:16:45 +0000 (Thu, 24 Sep 2009)
>>>>>>>>>>>
>>>>>>>>>>> Log Message:
>>>>>>>>>>> -----------
>>>>>>>>>>> Remove libusb-compat from 0.7 branch
>>>>>>>>>>>
>>>>>>>>>>> Modified Paths:
>>>>>>>>>>> --------------
>>>>>>>>>>>    branches/0.7/astlinux.config
>>>>>>>>>>>    branches/0.7/package/Config.in
>>>>>>>>>>>    branches/0.7/package/apcupsd/apcupsd.mk
>>>>>>>>>>>    branches/0.7/package/dahdi-linux/dahdi-linux.mk
>>>>>>>>>>>    branches/0.7/package/dahdi-tools/dahdi-tools.mk
>>>>>>>>>>>    branches/0.7/package/lcdproc/lcdproc.mk
>>>>>>>>>>>    branches/0.7/package/libftdi/libftdi.mk
>>>>>>>>>>>    branches/0.7/package/libusb/libusb.mk
>>>>>>>>>>>    branches/0.7/package/usbutils/usbutils.mk
>>>>>>>>>>>    branches/0.7/package/zaptel/zaptel.mk
>>>>>>>>>>>
>>>>>>>>>>> Added Paths:
>>>>>>>>>>> -----------
>>>>>>>>>>>    branches/0.7/package/libusb/libusb-config
>>>>>>>>>>>
>>>>>>>>>>> Removed Paths:
>>>>>>>>>>> -------------
>>>>>>>>>>>    branches/0.7/package/libusb-compat/
>>>>>>>>>>>    branches/0.7/package/usbutils/usbutils-makefile.patch
>>>>>>>>>>>             
>>>>>>>>>>>                 
>>>>>>>>>>>                     
>>>>>>>>>>>                       
>>>       
>

Um, yeah, 3327.

And not ALL of 3327 was related to libusb-1.0, as you seem to be asserting.


On 09/25/2009 02:39 PM, Darrick Hartman wrote:
> Do you have a specific commit in mind?  All of the libusb-1.0 related 
> changes were required to go.  We're not using libusb-1.0.  If there are 
> changes which contribute positively towards a stable release, I'd be all 
> ears for knowing which lines should go back in.
>
> Philip A. Prindeville wrote:
>   
>> Ok, so that accounts for one line... What about all of the rest of the
>> changes that were needlessly backed out?
>>
>>
>> On 09/25/2009 02:01 PM, Darrick Hartman wrote:
>>     
>>> Philip,
>>>
>>> usbutils has been built this way (without using zlib) for a very long 
>>> time (all of 0.6 for sure, probably longer).  If we don't link against 
>>> zlib, the .gz file is never created.  Granted, in 0.6 with did not 
>>> explicitly state --without-zlib, but that's because the order of 
>>> compilation was fixed in trunk.
>>>
>>> pciutils works the same way.  All I know is if usbutils and pciutils are 
>>> linked against zlib, that both lspci and lsusb take about 30-40 seconds 
>>> on more limited hardware.
>>>
>>>
>>>
>>> Philip A. Prindeville wrote:
>>>   
>>>       
>>>> You know what? You want to gratuitously diverge the branch from trunk,
>>>> that's your call.
>>>>
>>>> I don't recommend it.
>>>>
>>>> Deleting the usb.ids.gz file saves room in the ramfs, which as you
>>>> remember you said yesterday was getting crowded...
>>>>
>>>>
>>>>
>>>> On 09/25/2009 01:20 PM, Darrick Hartman wrote:
>>>>     
>>>>         
>>>>> Philip,
>>>>>
>>>>> What items won't build properly with the way 0.7 is right now?  Neither 
>>>>> Lonnie or I are seeing any breakage with the current status.
>>>>>
>>>>> What does compiling against zlib get us if we're not using the generated 
>>>>> file?  My understanding is that not linking against zlib or deleting the 
>>>>> usb.ids.gz file results in the same outcome.  If that's not correct, 
>>>>> please clarify.
>>>>>
>>>>> Philip A. Prindeville wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> So, can you make the necessary reversions please?
>>>>>>
>>>>>> -Philip
>>>>>>
>>>>>>
>>>>>> On 09/24/2009 11:42 AM, Philip A. Prindeville wrote:
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>> Since you didn't ask before making the changes, I figured you had that
>>>>>>> all worked out...
>>>>>>>
>>>>>>> Guess not.
>>>>>>>
>>>>>>> All you *really* needed to do, was switch "libusb-compat" back to
>>>>>>> "libusb" as a dependency, change "libusb-1.0" into "libusb" (or
>>>>>>> "-lusb-1.0" into "-lusb") wherever you saw that as a linker flag,
>>>>>>> disable BR2_PACKAGE_LIBUSB-COMPAT, and revert the version # and URL in
>>>>>>> package/libusb/libusb.mk (maybe also the setting for LIBUSB_CAT).
>>>>>>>
>>>>>>> That was it.
>>>>>>>
>>>>>>> The patch to libusb-config for instance is not needed, and should have
>>>>>>> been left out. And the extra flags being passed into Make, the shuffling
>>>>>>> of files, etc. was totally unnecessary and just confuses the issue.
>>>>>>>
>>>>>>> The patch to usbutils's makefile is correct, and fixes a bug... as well
>>>>>>> as being benign with earlier versions.
>>>>>>>
>>>>>>> And the fix leaving the linkage with zlib, but removing the usb.ids.gz
>>>>>>> file is the correct one: what install a file you're unequipped to read?
>>>>>>> That just wastes space...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 09/24/2009 05:11 AM, Lonnie Abelbeck wrote:
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>>>> Philip,
>>>>>>>>
>>>>>>>> I reverted usb to trunk-3312 in 0.7.
>>>>>>>>
>>>>>>>> The resulting 0.7 build appears to work properly.
>>>>>>>>
>>>>>>>> If you have any specific cleanups that were a part of your usb-compat  
>>>>>>>> changes I'm all ears.
>>>>>>>>
>>>>>>>> Lonnie
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sep 23, 2009, at 8:02 PM, Philip A. Prindeville wrote:
>>>>>>>>
>>>>>>>>   
>>>>>>>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>>>>> Some of what you're backing out is actually needed cleanup to broken
>>>>>>>>> makefiles.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 09/23/2009 05:16 PM, abe...@us... wrote:
>>>>>>>>>     
>>>>>>>>>       
>>>>>>>>>           
>>>>>>>>>               
>>>>>>>>>                   
>>>>>>>>>> Revision: 3327
>>>>>>>>>>          http://astlinux.svn.sourceforge.net/astlinux/?rev=3327&view=rev
>>>>>>>>>> Author:   abelbeck
>>>>>>>>>> Date:     2009-09-24 00:16:45 +0000 (Thu, 24 Sep 2009)
>>>>>>>>>>
>>>>>>>>>> Log Message:
>>>>>>>>>> -----------
>>>>>>>>>> Remove libusb-compat from 0.7 branch
>>>>>>>>>>
>>>>>>>>>> Modified Paths:
>>>>>>>>>> --------------
>>>>>>>>>>    branches/0.7/astlinux.config
>>>>>>>>>>    branches/0.7/package/Config.in
>>>>>>>>>>    branches/0.7/package/apcupsd/apcupsd.mk
>>>>>>>>>>    branches/0.7/package/dahdi-linux/dahdi-linux.mk
>>>>>>>>>>    branches/0.7/package/dahdi-tools/dahdi-tools.mk
>>>>>>>>>>    branches/0.7/package/lcdproc/lcdproc.mk
>>>>>>>>>>    branches/0.7/package/libftdi/libftdi.mk
>>>>>>>>>>    branches/0.7/package/libusb/libusb.mk
>>>>>>>>>>    branches/0.7/package/usbutils/usbutils.mk
>>>>>>>>>>    branches/0.7/package/zaptel/zaptel.mk
>>>>>>>>>>
>>>>>>>>>> Added Paths:
>>>>>>>>>> -----------
>>>>>>>>>>    branches/0.7/package/libusb/libusb-config
>>>>>>>>>>
>>>>>>>>>> Removed Paths:
>>>>>>>>>> -------------
>>>>>>>>>>    branches/0.7/package/libusb-compat/
>>>>>>>>>>    branches/0.7/package/usbutils/usbutils-makefile.patch
>>>>>>>>>>             
>>>>>>>>>>                 
>>>>>>>>>>                     
>>

Do you have a specific commit in mind?  All of the libusb-1.0 related 
changes were required to go.  We're not using libusb-1.0.  If there are 
changes which contribute positively towards a stable release, I'd be all 
ears for knowing which lines should go back in.

Philip A. Prindeville wrote:
> Ok, so that accounts for one line... What about all of the rest of the
> changes that were needlessly backed out?
> 
> 
> On 09/25/2009 02:01 PM, Darrick Hartman wrote:
>> Philip,
>>
>> usbutils has been built this way (without using zlib) for a very long 
>> time (all of 0.6 for sure, probably longer).  If we don't link against 
>> zlib, the .gz file is never created.  Granted, in 0.6 with did not 
>> explicitly state --without-zlib, but that's because the order of 
>> compilation was fixed in trunk.
>>
>> pciutils works the same way.  All I know is if usbutils and pciutils are 
>> linked against zlib, that both lspci and lsusb take about 30-40 seconds 
>> on more limited hardware.
>>
>>
>>
>> Philip A. Prindeville wrote:
>>   
>>> You know what? You want to gratuitously diverge the branch from trunk,
>>> that's your call.
>>>
>>> I don't recommend it.
>>>
>>> Deleting the usb.ids.gz file saves room in the ramfs, which as you
>>> remember you said yesterday was getting crowded...
>>>
>>>
>>>
>>> On 09/25/2009 01:20 PM, Darrick Hartman wrote:
>>>     
>>>> Philip,
>>>>
>>>> What items won't build properly with the way 0.7 is right now?  Neither 
>>>> Lonnie or I are seeing any breakage with the current status.
>>>>
>>>> What does compiling against zlib get us if we're not using the generated 
>>>> file?  My understanding is that not linking against zlib or deleting the 
>>>> usb.ids.gz file results in the same outcome.  If that's not correct, 
>>>> please clarify.
>>>>
>>>> Philip A. Prindeville wrote:
>>>>   
>>>>       
>>>>> So, can you make the necessary reversions please?
>>>>>
>>>>> -Philip
>>>>>
>>>>>
>>>>> On 09/24/2009 11:42 AM, Philip A. Prindeville wrote:
>>>>>     
>>>>>         
>>>>>> Since you didn't ask before making the changes, I figured you had that
>>>>>> all worked out...
>>>>>>
>>>>>> Guess not.
>>>>>>
>>>>>> All you *really* needed to do, was switch "libusb-compat" back to
>>>>>> "libusb" as a dependency, change "libusb-1.0" into "libusb" (or
>>>>>> "-lusb-1.0" into "-lusb") wherever you saw that as a linker flag,
>>>>>> disable BR2_PACKAGE_LIBUSB-COMPAT, and revert the version # and URL in
>>>>>> package/libusb/libusb.mk (maybe also the setting for LIBUSB_CAT).
>>>>>>
>>>>>> That was it.
>>>>>>
>>>>>> The patch to libusb-config for instance is not needed, and should have
>>>>>> been left out. And the extra flags being passed into Make, the shuffling
>>>>>> of files, etc. was totally unnecessary and just confuses the issue.
>>>>>>
>>>>>> The patch to usbutils's makefile is correct, and fixes a bug... as well
>>>>>> as being benign with earlier versions.
>>>>>>
>>>>>> And the fix leaving the linkage with zlib, but removing the usb.ids.gz
>>>>>> file is the correct one: what install a file you're unequipped to read?
>>>>>> That just wastes space...
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 09/24/2009 05:11 AM, Lonnie Abelbeck wrote:
>>>>>>   
>>>>>>       
>>>>>>           
>>>>>>> Philip,
>>>>>>>
>>>>>>> I reverted usb to trunk-3312 in 0.7.
>>>>>>>
>>>>>>> The resulting 0.7 build appears to work properly.
>>>>>>>
>>>>>>> If you have any specific cleanups that were a part of your usb-compat  
>>>>>>> changes I'm all ears.
>>>>>>>
>>>>>>> Lonnie
>>>>>>>
>>>>>>>
>>>>>>> On Sep 23, 2009, at 8:02 PM, Philip A. Prindeville wrote:
>>>>>>>
>>>>>>>   
>>>>>>>     
>>>>>>>         
>>>>>>>             
>>>>>>>> Some of what you're backing out is actually needed cleanup to broken
>>>>>>>> makefiles.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 09/23/2009 05:16 PM, abe...@us... wrote:
>>>>>>>>     
>>>>>>>>       
>>>>>>>>           
>>>>>>>>               
>>>>>>>>> Revision: 3327
>>>>>>>>>          http://astlinux.svn.sourceforge.net/astlinux/?rev=3327&view=rev
>>>>>>>>> Author:   abelbeck
>>>>>>>>> Date:     2009-09-24 00:16:45 +0000 (Thu, 24 Sep 2009)
>>>>>>>>>
>>>>>>>>> Log Message:
>>>>>>>>> -----------
>>>>>>>>> Remove libusb-compat from 0.7 branch
>>>>>>>>>
>>>>>>>>> Modified Paths:
>>>>>>>>> --------------
>>>>>>>>>    branches/0.7/astlinux.config
>>>>>>>>>    branches/0.7/package/Config.in
>>>>>>>>>    branches/0.7/package/apcupsd/apcupsd.mk
>>>>>>>>>    branches/0.7/package/dahdi-linux/dahdi-linux.mk
>>>>>>>>>    branches/0.7/package/dahdi-tools/dahdi-tools.mk
>>>>>>>>>    branches/0.7/package/lcdproc/lcdproc.mk
>>>>>>>>>    branches/0.7/package/libftdi/libftdi.mk
>>>>>>>>>    branches/0.7/package/libusb/libusb.mk
>>>>>>>>>    branches/0.7/package/usbutils/usbutils.mk
>>>>>>>>>    branches/0.7/package/zaptel/zaptel.mk
>>>>>>>>>
>>>>>>>>> Added Paths:
>>>>>>>>> -----------
>>>>>>>>>    branches/0.7/package/libusb/libusb-config
>>>>>>>>>
>>>>>>>>> Removed Paths:
>>>>>>>>> -------------
>>>>>>>>>    branches/0.7/package/libusb-compat/
>>>>>>>>>    branches/0.7/package/usbutils/usbutils-makefile.patch
>>>>>>>>>             
>>>>>>>>>                 
> 
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Ok, so that accounts for one line... What about all of the rest of the
changes that were needlessly backed out?


On 09/25/2009 02:01 PM, Darrick Hartman wrote:
> Philip,
>
> usbutils has been built this way (without using zlib) for a very long 
> time (all of 0.6 for sure, probably longer).  If we don't link against 
> zlib, the .gz file is never created.  Granted, in 0.6 with did not 
> explicitly state --without-zlib, but that's because the order of 
> compilation was fixed in trunk.
>
> pciutils works the same way.  All I know is if usbutils and pciutils are 
> linked against zlib, that both lspci and lsusb take about 30-40 seconds 
> on more limited hardware.
>
>
>
> Philip A. Prindeville wrote:
>   
>> You know what? You want to gratuitously diverge the branch from trunk,
>> that's your call.
>>
>> I don't recommend it.
>>
>> Deleting the usb.ids.gz file saves room in the ramfs, which as you
>> remember you said yesterday was getting crowded...
>>
>>
>>
>> On 09/25/2009 01:20 PM, Darrick Hartman wrote:
>>     
>>> Philip,
>>>
>>> What items won't build properly with the way 0.7 is right now?  Neither 
>>> Lonnie or I are seeing any breakage with the current status.
>>>
>>> What does compiling against zlib get us if we're not using the generated 
>>> file?  My understanding is that not linking against zlib or deleting the 
>>> usb.ids.gz file results in the same outcome.  If that's not correct, 
>>> please clarify.
>>>
>>> Philip A. Prindeville wrote:
>>>   
>>>       
>>>> So, can you make the necessary reversions please?
>>>>
>>>> -Philip
>>>>
>>>>
>>>> On 09/24/2009 11:42 AM, Philip A. Prindeville wrote:
>>>>     
>>>>         
>>>>> Since you didn't ask before making the changes, I figured you had that
>>>>> all worked out...
>>>>>
>>>>> Guess not.
>>>>>
>>>>> All you *really* needed to do, was switch "libusb-compat" back to
>>>>> "libusb" as a dependency, change "libusb-1.0" into "libusb" (or
>>>>> "-lusb-1.0" into "-lusb") wherever you saw that as a linker flag,
>>>>> disable BR2_PACKAGE_LIBUSB-COMPAT, and revert the version # and URL in
>>>>> package/libusb/libusb.mk (maybe also the setting for LIBUSB_CAT).
>>>>>
>>>>> That was it.
>>>>>
>>>>> The patch to libusb-config for instance is not needed, and should have
>>>>> been left out. And the extra flags being passed into Make, the shuffling
>>>>> of files, etc. was totally unnecessary and just confuses the issue.
>>>>>
>>>>> The patch to usbutils's makefile is correct, and fixes a bug... as well
>>>>> as being benign with earlier versions.
>>>>>
>>>>> And the fix leaving the linkage with zlib, but removing the usb.ids.gz
>>>>> file is the correct one: what install a file you're unequipped to read?
>>>>> That just wastes space...
>>>>>
>>>>>
>>>>>
>>>>> On 09/24/2009 05:11 AM, Lonnie Abelbeck wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> Philip,
>>>>>>
>>>>>> I reverted usb to trunk-3312 in 0.7.
>>>>>>
>>>>>> The resulting 0.7 build appears to work properly.
>>>>>>
>>>>>> If you have any specific cleanups that were a part of your usb-compat  
>>>>>> changes I'm all ears.
>>>>>>
>>>>>> Lonnie
>>>>>>
>>>>>>
>>>>>> On Sep 23, 2009, at 8:02 PM, Philip A. Prindeville wrote:
>>>>>>
>>>>>>   
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>> Some of what you're backing out is actually needed cleanup to broken
>>>>>>> makefiles.
>>>>>>>
>>>>>>>
>>>>>>> On 09/23/2009 05:16 PM, abe...@us... wrote:
>>>>>>>     
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>>>> Revision: 3327
>>>>>>>>          http://astlinux.svn.sourceforge.net/astlinux/?rev=3327&view=rev
>>>>>>>> Author:   abelbeck
>>>>>>>> Date:     2009-09-24 00:16:45 +0000 (Thu, 24 Sep 2009)
>>>>>>>>
>>>>>>>> Log Message:
>>>>>>>> -----------
>>>>>>>> Remove libusb-compat from 0.7 branch
>>>>>>>>
>>>>>>>> Modified Paths:
>>>>>>>> --------------
>>>>>>>>    branches/0.7/astlinux.config
>>>>>>>>    branches/0.7/package/Config.in
>>>>>>>>    branches/0.7/package/apcupsd/apcupsd.mk
>>>>>>>>    branches/0.7/package/dahdi-linux/dahdi-linux.mk
>>>>>>>>    branches/0.7/package/dahdi-tools/dahdi-tools.mk
>>>>>>>>    branches/0.7/package/lcdproc/lcdproc.mk
>>>>>>>>    branches/0.7/package/libftdi/libftdi.mk
>>>>>>>>    branches/0.7/package/libusb/libusb.mk
>>>>>>>>    branches/0.7/package/usbutils/usbutils.mk
>>>>>>>>    branches/0.7/package/zaptel/zaptel.mk
>>>>>>>>
>>>>>>>> Added Paths:
>>>>>>>> -----------
>>>>>>>>    branches/0.7/package/libusb/libusb-config
>>>>>>>>
>>>>>>>> Removed Paths:
>>>>>>>> -------------
>>>>>>>>    branches/0.7/package/libusb-compat/
>>>>>>>>    branches/0.7/package/usbutils/usbutils-makefile.patch
>>>>>>>>             
>>>>>>>>                 
>>

Philip,

usbutils has been built this way (without using zlib) for a very long 
time (all of 0.6 for sure, probably longer).  If we don't link against 
zlib, the .gz file is never created.  Granted, in 0.6 with did not 
explicitly state --without-zlib, but that's because the order of 
compilation was fixed in trunk.

pciutils works the same way.  All I know is if usbutils and pciutils are 
linked against zlib, that both lspci and lsusb take about 30-40 seconds 
on more limited hardware.



Philip A. Prindeville wrote:
> You know what? You want to gratuitously diverge the branch from trunk,
> that's your call.
> 
> I don't recommend it.
> 
> Deleting the usb.ids.gz file saves room in the ramfs, which as you
> remember you said yesterday was getting crowded...
> 
> 
> 
> On 09/25/2009 01:20 PM, Darrick Hartman wrote:
>> Philip,
>>
>> What items won't build properly with the way 0.7 is right now?  Neither 
>> Lonnie or I are seeing any breakage with the current status.
>>
>> What does compiling against zlib get us if we're not using the generated 
>> file?  My understanding is that not linking against zlib or deleting the 
>> usb.ids.gz file results in the same outcome.  If that's not correct, 
>> please clarify.
>>
>> Philip A. Prindeville wrote:
>>   
>>> So, can you make the necessary reversions please?
>>>
>>> -Philip
>>>
>>>
>>> On 09/24/2009 11:42 AM, Philip A. Prindeville wrote:
>>>     
>>>> Since you didn't ask before making the changes, I figured you had that
>>>> all worked out...
>>>>
>>>> Guess not.
>>>>
>>>> All you *really* needed to do, was switch "libusb-compat" back to
>>>> "libusb" as a dependency, change "libusb-1.0" into "libusb" (or
>>>> "-lusb-1.0" into "-lusb") wherever you saw that as a linker flag,
>>>> disable BR2_PACKAGE_LIBUSB-COMPAT, and revert the version # and URL in
>>>> package/libusb/libusb.mk (maybe also the setting for LIBUSB_CAT).
>>>>
>>>> That was it.
>>>>
>>>> The patch to libusb-config for instance is not needed, and should have
>>>> been left out. And the extra flags being passed into Make, the shuffling
>>>> of files, etc. was totally unnecessary and just confuses the issue.
>>>>
>>>> The patch to usbutils's makefile is correct, and fixes a bug... as well
>>>> as being benign with earlier versions.
>>>>
>>>> And the fix leaving the linkage with zlib, but removing the usb.ids.gz
>>>> file is the correct one: what install a file you're unequipped to read?
>>>> That just wastes space...
>>>>
>>>>
>>>>
>>>> On 09/24/2009 05:11 AM, Lonnie Abelbeck wrote:
>>>>   
>>>>       
>>>>> Philip,
>>>>>
>>>>> I reverted usb to trunk-3312 in 0.7.
>>>>>
>>>>> The resulting 0.7 build appears to work properly.
>>>>>
>>>>> If you have any specific cleanups that were a part of your usb-compat  
>>>>> changes I'm all ears.
>>>>>
>>>>> Lonnie
>>>>>
>>>>>
>>>>> On Sep 23, 2009, at 8:02 PM, Philip A. Prindeville wrote:
>>>>>
>>>>>   
>>>>>     
>>>>>         
>>>>>> Some of what you're backing out is actually needed cleanup to broken
>>>>>> makefiles.
>>>>>>
>>>>>>
>>>>>> On 09/23/2009 05:16 PM, abe...@us... wrote:
>>>>>>     
>>>>>>       
>>>>>>           
>>>>>>> Revision: 3327
>>>>>>>          http://astlinux.svn.sourceforge.net/astlinux/?rev=3327&view=rev
>>>>>>> Author:   abelbeck
>>>>>>> Date:     2009-09-24 00:16:45 +0000 (Thu, 24 Sep 2009)
>>>>>>>
>>>>>>> Log Message:
>>>>>>> -----------
>>>>>>> Remove libusb-compat from 0.7 branch
>>>>>>>
>>>>>>> Modified Paths:
>>>>>>> --------------
>>>>>>>    branches/0.7/astlinux.config
>>>>>>>    branches/0.7/package/Config.in
>>>>>>>    branches/0.7/package/apcupsd/apcupsd.mk
>>>>>>>    branches/0.7/package/dahdi-linux/dahdi-linux.mk
>>>>>>>    branches/0.7/package/dahdi-tools/dahdi-tools.mk
>>>>>>>    branches/0.7/package/lcdproc/lcdproc.mk
>>>>>>>    branches/0.7/package/libftdi/libftdi.mk
>>>>>>>    branches/0.7/package/libusb/libusb.mk
>>>>>>>    branches/0.7/package/usbutils/usbutils.mk
>>>>>>>    branches/0.7/package/zaptel/zaptel.mk
>>>>>>>
>>>>>>> Added Paths:
>>>>>>> -----------
>>>>>>>    branches/0.7/package/libusb/libusb-config
>>>>>>>
>>>>>>> Removed Paths:
>>>>>>> -------------
>>>>>>>    branches/0.7/package/libusb-compat/
>>>>>>>    branches/0.7/package/usbutils/usbutils-makefile.patch
>>>>>>>             
> 
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

You know what? You want to gratuitously diverge the branch from trunk,
that's your call.

I don't recommend it.

Deleting the usb.ids.gz file saves room in the ramfs, which as you
remember you said yesterday was getting crowded...



On 09/25/2009 01:20 PM, Darrick Hartman wrote:
> Philip,
>
> What items won't build properly with the way 0.7 is right now?  Neither 
> Lonnie or I are seeing any breakage with the current status.
>
> What does compiling against zlib get us if we're not using the generated 
> file?  My understanding is that not linking against zlib or deleting the 
> usb.ids.gz file results in the same outcome.  If that's not correct, 
> please clarify.
>
> Philip A. Prindeville wrote:
>   
>> So, can you make the necessary reversions please?
>>
>> -Philip
>>
>>
>> On 09/24/2009 11:42 AM, Philip A. Prindeville wrote:
>>     
>>> Since you didn't ask before making the changes, I figured you had that
>>> all worked out...
>>>
>>> Guess not.
>>>
>>> All you *really* needed to do, was switch "libusb-compat" back to
>>> "libusb" as a dependency, change "libusb-1.0" into "libusb" (or
>>> "-lusb-1.0" into "-lusb") wherever you saw that as a linker flag,
>>> disable BR2_PACKAGE_LIBUSB-COMPAT, and revert the version # and URL in
>>> package/libusb/libusb.mk (maybe also the setting for LIBUSB_CAT).
>>>
>>> That was it.
>>>
>>> The patch to libusb-config for instance is not needed, and should have
>>> been left out. And the extra flags being passed into Make, the shuffling
>>> of files, etc. was totally unnecessary and just confuses the issue.
>>>
>>> The patch to usbutils's makefile is correct, and fixes a bug... as well
>>> as being benign with earlier versions.
>>>
>>> And the fix leaving the linkage with zlib, but removing the usb.ids.gz
>>> file is the correct one: what install a file you're unequipped to read?
>>> That just wastes space...
>>>
>>>
>>>
>>> On 09/24/2009 05:11 AM, Lonnie Abelbeck wrote:
>>>   
>>>       
>>>> Philip,
>>>>
>>>> I reverted usb to trunk-3312 in 0.7.
>>>>
>>>> The resulting 0.7 build appears to work properly.
>>>>
>>>> If you have any specific cleanups that were a part of your usb-compat  
>>>> changes I'm all ears.
>>>>
>>>> Lonnie
>>>>
>>>>
>>>> On Sep 23, 2009, at 8:02 PM, Philip A. Prindeville wrote:
>>>>
>>>>   
>>>>     
>>>>         
>>>>> Some of what you're backing out is actually needed cleanup to broken
>>>>> makefiles.
>>>>>
>>>>>
>>>>> On 09/23/2009 05:16 PM, abe...@us... wrote:
>>>>>     
>>>>>       
>>>>>           
>>>>>> Revision: 3327
>>>>>>          http://astlinux.svn.sourceforge.net/astlinux/?rev=3327&view=rev
>>>>>> Author:   abelbeck
>>>>>> Date:     2009-09-24 00:16:45 +0000 (Thu, 24 Sep 2009)
>>>>>>
>>>>>> Log Message:
>>>>>> -----------
>>>>>> Remove libusb-compat from 0.7 branch
>>>>>>
>>>>>> Modified Paths:
>>>>>> --------------
>>>>>>    branches/0.7/astlinux.config
>>>>>>    branches/0.7/package/Config.in
>>>>>>    branches/0.7/package/apcupsd/apcupsd.mk
>>>>>>    branches/0.7/package/dahdi-linux/dahdi-linux.mk
>>>>>>    branches/0.7/package/dahdi-tools/dahdi-tools.mk
>>>>>>    branches/0.7/package/lcdproc/lcdproc.mk
>>>>>>    branches/0.7/package/libftdi/libftdi.mk
>>>>>>    branches/0.7/package/libusb/libusb.mk
>>>>>>    branches/0.7/package/usbutils/usbutils.mk
>>>>>>    branches/0.7/package/zaptel/zaptel.mk
>>>>>>
>>>>>> Added Paths:
>>>>>> -----------
>>>>>>    branches/0.7/package/libusb/libusb-config
>>>>>>
>>>>>> Removed Paths:
>>>>>> -------------
>>>>>>    branches/0.7/package/libusb-compat/
>>>>>>    branches/0.7/package/usbutils/usbutils-makefile.patch
>>>>>>             
>

Philip,

What items won't build properly with the way 0.7 is right now?  Neither 
Lonnie or I are seeing any breakage with the current status.

What does compiling against zlib get us if we're not using the generated 
file?  My understanding is that not linking against zlib or deleting the 
usb.ids.gz file results in the same outcome.  If that's not correct, 
please clarify.

Philip A. Prindeville wrote:
> So, can you make the necessary reversions please?
> 
> -Philip
> 
> 
> On 09/24/2009 11:42 AM, Philip A. Prindeville wrote:
>> Since you didn't ask before making the changes, I figured you had that
>> all worked out...
>>
>> Guess not.
>>
>> All you *really* needed to do, was switch "libusb-compat" back to
>> "libusb" as a dependency, change "libusb-1.0" into "libusb" (or
>> "-lusb-1.0" into "-lusb") wherever you saw that as a linker flag,
>> disable BR2_PACKAGE_LIBUSB-COMPAT, and revert the version # and URL in
>> package/libusb/libusb.mk (maybe also the setting for LIBUSB_CAT).
>>
>> That was it.
>>
>> The patch to libusb-config for instance is not needed, and should have
>> been left out. And the extra flags being passed into Make, the shuffling
>> of files, etc. was totally unnecessary and just confuses the issue.
>>
>> The patch to usbutils's makefile is correct, and fixes a bug... as well
>> as being benign with earlier versions.
>>
>> And the fix leaving the linkage with zlib, but removing the usb.ids.gz
>> file is the correct one: what install a file you're unequipped to read?
>> That just wastes space...
>>
>>
>>
>> On 09/24/2009 05:11 AM, Lonnie Abelbeck wrote:
>>   
>>> Philip,
>>>
>>> I reverted usb to trunk-3312 in 0.7.
>>>
>>> The resulting 0.7 build appears to work properly.
>>>
>>> If you have any specific cleanups that were a part of your usb-compat  
>>> changes I'm all ears.
>>>
>>> Lonnie
>>>
>>>
>>> On Sep 23, 2009, at 8:02 PM, Philip A. Prindeville wrote:
>>>
>>>   
>>>     
>>>> Some of what you're backing out is actually needed cleanup to broken
>>>> makefiles.
>>>>
>>>>
>>>> On 09/23/2009 05:16 PM, abe...@us... wrote:
>>>>     
>>>>       
>>>>> Revision: 3327
>>>>>          http://astlinux.svn.sourceforge.net/astlinux/?rev=3327&view=rev
>>>>> Author:   abelbeck
>>>>> Date:     2009-09-24 00:16:45 +0000 (Thu, 24 Sep 2009)
>>>>>
>>>>> Log Message:
>>>>> -----------
>>>>> Remove libusb-compat from 0.7 branch
>>>>>
>>>>> Modified Paths:
>>>>> --------------
>>>>>    branches/0.7/astlinux.config
>>>>>    branches/0.7/package/Config.in
>>>>>    branches/0.7/package/apcupsd/apcupsd.mk
>>>>>    branches/0.7/package/dahdi-linux/dahdi-linux.mk
>>>>>    branches/0.7/package/dahdi-tools/dahdi-tools.mk
>>>>>    branches/0.7/package/lcdproc/lcdproc.mk
>>>>>    branches/0.7/package/libftdi/libftdi.mk
>>>>>    branches/0.7/package/libusb/libusb.mk
>>>>>    branches/0.7/package/usbutils/usbutils.mk
>>>>>    branches/0.7/package/zaptel/zaptel.mk
>>>>>
>>>>> Added Paths:
>>>>> -----------
>>>>>    branches/0.7/package/libusb/libusb-config
>>>>>
>>>>> Removed Paths:
>>>>> -------------
>>>>>    branches/0.7/package/libusb-compat/
>>>>>    branches/0.7/package/usbutils/usbutils-makefile.patch

So, can you make the necessary reversions please?

-Philip


On 09/24/2009 11:42 AM, Philip A. Prindeville wrote:
> Since you didn't ask before making the changes, I figured you had that
> all worked out...
>
> Guess not.
>
> All you *really* needed to do, was switch "libusb-compat" back to
> "libusb" as a dependency, change "libusb-1.0" into "libusb" (or
> "-lusb-1.0" into "-lusb") wherever you saw that as a linker flag,
> disable BR2_PACKAGE_LIBUSB-COMPAT, and revert the version # and URL in
> package/libusb/libusb.mk (maybe also the setting for LIBUSB_CAT).
>
> That was it.
>
> The patch to libusb-config for instance is not needed, and should have
> been left out. And the extra flags being passed into Make, the shuffling
> of files, etc. was totally unnecessary and just confuses the issue.
>
> The patch to usbutils's makefile is correct, and fixes a bug... as well
> as being benign with earlier versions.
>
> And the fix leaving the linkage with zlib, but removing the usb.ids.gz
> file is the correct one: what install a file you're unequipped to read?
> That just wastes space...
>
>
>
> On 09/24/2009 05:11 AM, Lonnie Abelbeck wrote:
>   
>> Philip,
>>
>> I reverted usb to trunk-3312 in 0.7.
>>
>> The resulting 0.7 build appears to work properly.
>>
>> If you have any specific cleanups that were a part of your usb-compat  
>> changes I'm all ears.
>>
>> Lonnie
>>
>>
>> On Sep 23, 2009, at 8:02 PM, Philip A. Prindeville wrote:
>>
>>   
>>     
>>> Some of what you're backing out is actually needed cleanup to broken
>>> makefiles.
>>>
>>>
>>> On 09/23/2009 05:16 PM, abe...@us... wrote:
>>>     
>>>       
>>>> Revision: 3327
>>>>          http://astlinux.svn.sourceforge.net/astlinux/?rev=3327&view=rev
>>>> Author:   abelbeck
>>>> Date:     2009-09-24 00:16:45 +0000 (Thu, 24 Sep 2009)
>>>>
>>>> Log Message:
>>>> -----------
>>>> Remove libusb-compat from 0.7 branch
>>>>
>>>> Modified Paths:
>>>> --------------
>>>>    branches/0.7/astlinux.config
>>>>    branches/0.7/package/Config.in
>>>>    branches/0.7/package/apcupsd/apcupsd.mk
>>>>    branches/0.7/package/dahdi-linux/dahdi-linux.mk
>>>>    branches/0.7/package/dahdi-tools/dahdi-tools.mk
>>>>    branches/0.7/package/lcdproc/lcdproc.mk
>>>>    branches/0.7/package/libftdi/libftdi.mk
>>>>    branches/0.7/package/libusb/libusb.mk
>>>>    branches/0.7/package/usbutils/usbutils.mk
>>>>    branches/0.7/package/zaptel/zaptel.mk
>>>>
>>>> Added Paths:
>>>> -----------
>>>>    branches/0.7/package/libusb/libusb-config
>>>>
>>>> Removed Paths:
>>>> -------------
>>>>    branches/0.7/package/libusb-compat/
>>>>    branches/0.7/package/usbutils/usbutils-makefile.patch
>>>>
>>>>       
>>>>         
>>     
>

Since you didn't ask before making the changes, I figured you had that
all worked out...

Guess not.

All you *really* needed to do, was switch "libusb-compat" back to
"libusb" as a dependency, change "libusb-1.0" into "libusb" (or
"-lusb-1.0" into "-lusb") wherever you saw that as a linker flag,
disable BR2_PACKAGE_LIBUSB-COMPAT, and revert the version # and URL in
package/libusb/libusb.mk (maybe also the setting for LIBUSB_CAT).

That was it.

The patch to libusb-config for instance is not needed, and should have
been left out. And the extra flags being passed into Make, the shuffling
of files, etc. was totally unnecessary and just confuses the issue.

The patch to usbutils's makefile is correct, and fixes a bug... as well
as being benign with earlier versions.

And the fix leaving the linkage with zlib, but removing the usb.ids.gz
file is the correct one: what install a file you're unequipped to read?
That just wastes space...



On 09/24/2009 05:11 AM, Lonnie Abelbeck wrote:
> Philip,
>
> I reverted usb to trunk-3312 in 0.7.
>
> The resulting 0.7 build appears to work properly.
>
> If you have any specific cleanups that were a part of your usb-compat  
> changes I'm all ears.
>
> Lonnie
>
>
> On Sep 23, 2009, at 8:02 PM, Philip A. Prindeville wrote:
>
>   
>> Some of what you're backing out is actually needed cleanup to broken
>> makefiles.
>>
>>
>> On 09/23/2009 05:16 PM, abe...@us... wrote:
>>     
>>> Revision: 3327
>>>          http://astlinux.svn.sourceforge.net/astlinux/?rev=3327&view=rev
>>> Author:   abelbeck
>>> Date:     2009-09-24 00:16:45 +0000 (Thu, 24 Sep 2009)
>>>
>>> Log Message:
>>> -----------
>>> Remove libusb-compat from 0.7 branch
>>>
>>> Modified Paths:
>>> --------------
>>>    branches/0.7/astlinux.config
>>>    branches/0.7/package/Config.in
>>>    branches/0.7/package/apcupsd/apcupsd.mk
>>>    branches/0.7/package/dahdi-linux/dahdi-linux.mk
>>>    branches/0.7/package/dahdi-tools/dahdi-tools.mk
>>>    branches/0.7/package/lcdproc/lcdproc.mk
>>>    branches/0.7/package/libftdi/libftdi.mk
>>>    branches/0.7/package/libusb/libusb.mk
>>>    branches/0.7/package/usbutils/usbutils.mk
>>>    branches/0.7/package/zaptel/zaptel.mk
>>>
>>> Added Paths:
>>> -----------
>>>    branches/0.7/package/libusb/libusb-config
>>>
>>> Removed Paths:
>>> -------------
>>>    branches/0.7/package/libusb-compat/
>>>    branches/0.7/package/usbutils/usbutils-makefile.patch
>>>
>>>       
>

kristian.kielhofner wrote:
> On Thu, Sep 24, 2009 at 11:26 AM, Darrick Hartman
> <dha...@dj...> wrote:
>> The squashfs image is 46M.  If that's expanded, then copied into ram,
>> it's going to exceed the size of the 90M ramdisk created for asturo.
>>
> 
>   That's pretty large...  Some of my old branches still come in at about 34MB.

The new moh files are quite a bit larger than the older ones.  (almost 
twice as large and we're deleting the really big ones).

There are also some other components which added some size recently. 
Wanpipe has a pretty big footprint, some of which could be reduced.