[Fuego] dbench no longer builds on any of my boards

[Fuego] dbench no longer builds on any of my boards

[Tim.Bird]

I should have held off ACK-ing the patches until my test runs completed.

That issue you mentioned with  dbench requiring libpopt is a killer.
The previous dbench was building for all of my boards, and this one
doesn't build for any of them (OK - that's only 3 toolchains, but still).

The default debian-armhf toolchain doesn't include popt.h, nor
does the yocto project SDK for aarch64, nor does the default
debian x86_64 toolchain.

Is there any way to work around or remove this dependency?

Two options come to mind:
 - patch the code to use something else
 - include the popt code in the test sources, and build it before building dbench.

Let me know what you think.
 -- Tim
 

Re: [Fuego] dbench no longer builds on any of my boards

[Daniel Sangorrin]

> -----Original Message-----
> From: Tim.Bird@sony.com [mailto:Tim.Bird@sony.com]
> Sent: Tuesday, March 27, 2018 9:24 AM
> To: daniel.sangorrin@toshiba.co.jp; fuego@lists.linuxfoundation.org
> Subject: dbench no longer builds on any of my boards
> 
> I should have held off ACK-ing the patches until my test runs completed.
> 
> That issue you mentioned with  dbench requiring libpopt is a killer.

Yes, it is  a killer.

> The previous dbench was building for all of my boards, and this one
> doesn't build for any of them (OK - that's only 3 toolchains, but still).
> 
> The default debian-armhf toolchain doesn't include popt.h, nor
> does the yocto project SDK for aarch64, nor does the default
> debian x86_64 toolchain.

For debian toolchains all you need to do is install the libpopt-dev library.
Note, that I already tell you that  on the error message. We could add that
library to the Dockerfile and the arm toolchain installer script. However,
now I am thinking of a different approach. Currently I am fixing the kernel
build test, and I have added a "dependencies" item to test.yaml. The idea
is to keep track of the build dependences of each test separately not in
the Dockerfile where everything is mixed and we have no control.

For Yocto generated SDK, you would need to add the library to your sdk. Or
easier, add the dbench test to your target filesystem.
 
> Is there any way to work around or remove this dependency?
> Two options come to mind:
>  - patch the code to use something else
>  - include the popt code in the test sources, and build it before building dbench.
> 
> Let me know what you think.

OK, I will work on that.

Thanks,
Daniel

Re: [Fuego] dbench no longer builds on any of my boards

[Tim.Bird]

> -----Original Message-----
> From: Daniel Sangorrin 
> 
> > -----Original Message-----
> > From: Tim.Bird@sony.com 
> > I should have held off ACK-ing the patches until my test runs completed.
> >
> > That issue you mentioned with  dbench requiring libpopt is a killer.
> 
> Yes, it is  a killer.
> 
> > The previous dbench was building for all of my boards, and this one
> > doesn't build for any of them (OK - that's only 3 toolchains, but still).
> >
> > The default debian-armhf toolchain doesn't include popt.h, nor
> > does the yocto project SDK for aarch64, nor does the default
> > debian x86_64 toolchain.
> 
> For debian toolchains all you need to do is install the libpopt-dev library.
> Note, that I already tell you that  on the error message. We could add that
> library to the Dockerfile and the arm toolchain installer script. However,
> now I am thinking of a different approach. Currently I am fixing the kernel
> build test, and I have added a "dependencies" item to test.yaml. The idea
> is to keep track of the build dependences of each test separately not in
> the Dockerfile where everything is mixed and we have no control.

The profusion developers ran into the same issue, and started working on
it.  Basically, I think the debian packages needed for test building should be
separated from those in the base "Fuego distribution".  We can add
libpopt-dev to the toolchain installer script (I have nothing against that).
But in general this solution doesn't scale.   If we have thousands of tests,
we can't be installing every library in existence.  Each test should indicate
its own build dependencies (as you say), and we should only install the
ones needed for the tests that are installed in the system.
> 
> For Yocto generated SDK, you would need to add the library to your sdk. Or
> easier, add the dbench test to your target filesystem.

The problem with adding dbench to the target system is that this is
not a solution for testing final products.  Final products should not have a bunch
of extra testing binaries on them.  Most consumer products I've worked on
have two configurations: the developer configuration and the production
configuration.  The production configuration usually has all the testing material
stripped out.  This is especially important for low-footprint devices.

> 
> > Is there any way to work around or remove this dependency?
> > Two options come to mind:
> >  - patch the code to use something else
> >  - include the popt code in the test sources, and build it before building
> dbench.
> >
> > Let me know what you think.
> 
> OK, I will work on that.

Which item are you working on?  I was going to take a look at dbench and see
how dependent it is on libpopt.  They just added this recently, so it might
not be that tightly integrated yet.
 -- Tim

Re: [Fuego] dbench no longer builds on any of my boards

[Daniel Sangorrin]

> -----Original Message-----
> From: Tim.Bird@sony.com [mailto:Tim.Bird@sony.com]
> Sent: Tuesday, March 27, 2018 9:45 AM
> To: daniel.sangorrin@toshiba.co.jp; fuego@lists.linuxfoundation.org
> Subject: RE: dbench no longer builds on any of my boards
> 
> > -----Original Message-----
> > From: Daniel Sangorrin
> >
> > > -----Original Message-----
> > > From: Tim.Bird@sony.com
> > > I should have held off ACK-ing the patches until my test runs completed.
> > >
> > > That issue you mentioned with  dbench requiring libpopt is a killer.
> >
> > Yes, it is  a killer.
> >
> > > The previous dbench was building for all of my boards, and this one
> > > doesn't build for any of them (OK - that's only 3 toolchains, but still).
> > >
> > > The default debian-armhf toolchain doesn't include popt.h, nor
> > > does the yocto project SDK for aarch64, nor does the default
> > > debian x86_64 toolchain.
> >
> > For debian toolchains all you need to do is install the libpopt-dev library.
> > Note, that I already tell you that  on the error message. We could add that
> > library to the Dockerfile and the arm toolchain installer script. However,
> > now I am thinking of a different approach. Currently I am fixing the kernel
> > build test, and I have added a "dependencies" item to test.yaml. The idea
> > is to keep track of the build dependences of each test separately not in
> > the Dockerfile where everything is mixed and we have no control.
> 
> The profusion developers ran into the same issue, and started working on
> it.  Basically, I think the debian packages needed for test building should be
> separated from those in the base "Fuego distribution".  We can add
> libpopt-dev to the toolchain installer script (I have nothing against that).
> But in general this solution doesn't scale.   If we have thousands of tests,
> we can't be installing every library in existence.  Each test should indicate
> its own build dependencies (as you say), and we should only install the
> ones needed for the tests that are installed in the system.
> >
> > For Yocto generated SDK, you would need to add the library to your sdk. Or
> > easier, add the dbench test to your target filesystem.
> 
> The problem with adding dbench to the target system is that this is
> not a solution for testing final products.  Final products should not have a bunch
> of extra testing binaries on them.  Most consumer products I've worked on
> have two configurations: the developer configuration and the production
> configuration.  The production configuration usually has all the testing material
> stripped out.  This is especially important for low-footprint devices.
> 
> >
> > > Is there any way to work around or remove this dependency?
> > > Two options come to mind:
> > >  - patch the code to use something else
> > >  - include the popt code in the test sources, and build it before building
> > dbench.
> > >
> > > Let me know what you think.
> >
> > OK, I will work on that.
> 
> Which item are you working on?  I was going to take a look at dbench and see
> how dependent it is on libpopt.  They just added this recently, so it might
> not be that tightly integrated yet

It seems popt is no longer maintained although still used by samba (dbench comes from here), rsync and other programs according to
https://stackoverflow.com/questions/189972/argument-parsing-helpers-for-c-unix

Perhaps, the best would be to talk with the upstream developers and see if they would
accept a patch that uses a different argument parser.
What do you think?

Thanks,
Daniel

Re: [Fuego] dbench no longer builds on any of my boards

[Tim.Bird]

> -----Original Message-----
> From: Daniel Sangorrin on Monday, March 26, 2018 6:03 PM
> > -----Original Message-----
> > From: Tim.Bird@sony.com 
> > > -----Original Message-----
> > > From: Daniel Sangorrin
> > >
> > > > -----Original Message-----
> > > > From: Tim.Bird@sony.com
> > > > I should have held off ACK-ing the patches until my test runs
> completed.
> > > >
> > > > That issue you mentioned with  dbench requiring libpopt is a killer.
> > >
> > > Yes, it is  a killer.
> > >
> > > > The previous dbench was building for all of my boards, and this one
> > > > doesn't build for any of them (OK - that's only 3 toolchains, but still).
> > > >
> > > > The default debian-armhf toolchain doesn't include popt.h, nor
> > > > does the yocto project SDK for aarch64, nor does the default
> > > > debian x86_64 toolchain.
> > >
> > > For debian toolchains all you need to do is install the libpopt-dev library.
> > > Note, that I already tell you that  on the error message. We could add
> that
> > > library to the Dockerfile and the arm toolchain installer script. However,
> > > now I am thinking of a different approach. Currently I am fixing the kernel
> > > build test, and I have added a "dependencies" item to test.yaml. The idea
> > > is to keep track of the build dependences of each test separately not in
> > > the Dockerfile where everything is mixed and we have no control.
> >
> > The profusion developers ran into the same issue, and started working on
> > it.  Basically, I think the debian packages needed for test building should be
> > separated from those in the base "Fuego distribution".  We can add
> > libpopt-dev to the toolchain installer script (I have nothing against that).
> > But in general this solution doesn't scale.   If we have thousands of tests,
> > we can't be installing every library in existence.  Each test should indicate
> > its own build dependencies (as you say), and we should only install the
> > ones needed for the tests that are installed in the system.
> > >
> > > For Yocto generated SDK, you would need to add the library to your sdk.
> Or
> > > easier, add the dbench test to your target filesystem.
> >
> > The problem with adding dbench to the target system is that this is
> > not a solution for testing final products.  Final products should not have a
> bunch
> > of extra testing binaries on them.  Most consumer products I've worked on
> > have two configurations: the developer configuration and the production
> > configuration.  The production configuration usually has all the testing
> material
> > stripped out.  This is especially important for low-footprint devices.
> >
> > >
> > > > Is there any way to work around or remove this dependency?
> > > > Two options come to mind:
> > > >  - patch the code to use something else
> > > >  - include the popt code in the test sources, and build it before building
> > > dbench.
> > > >
> > > > Let me know what you think.
> > >
> > > OK, I will work on that.
> >
> > Which item are you working on?  I was going to take a look at dbench and
> see
> > how dependent it is on libpopt.  They just added this recently, so it might
> > not be that tightly integrated yet
> 
> It seems popt is no longer maintained although still used by samba (dbench
> comes from here), rsync and other programs according to
> https://stackoverflow.com/questions/189972/argument-parsing-helpers-
> for-c-unix
> 
> Perhaps, the best would be to talk with the upstream developers and see if
> they would
> accept a patch that uses a different argument parser.
> What do you think?

if popt is no longer maintained, it will be increasingly difficult to obtain
or see pre-integrated into toolchains and SDKs.  I think the approach
of removing the dependency from dbench is best.

 -- Tim

Re: [Fuego] dbench no longer builds on any of my boards

[Daniel Sangorrin]

> -----Original Message-----
> From: Tim.Bird@sony.com [mailto:Tim.Bird@sony.com]
> >
> > Perhaps, the best would be to talk with the upstream developers and see if
> > they would
> > accept a patch that uses a different argument parser.
> > What do you think?
> 
> if popt is no longer maintained, it will be increasingly difficult to obtain
> or see pre-integrated into toolchains and SDKs.  I think the approach
> of removing the dependency from dbench is best.

That's what I meant by replacing it with a different argument parser.
Do you prefer doing it as a patch, or upstream?

Thanks,
Daniel

Re: [Fuego] dbench no longer builds on any of my boards

[Tim.Bird]

> -----Original Message-----
> From: Daniel Sangorrin [mailto:daniel.sangorrin@toshiba.co.jp]
> Sent: Monday, March 26, 2018 7:15 PM
> To: Bird, Timothy <Tim.Bird@sony.com>; fuego@lists.linuxfoundation.org
> Subject: RE: [Fuego] dbench no longer builds on any of my boards
> 
> > -----Original Message-----
> > From: Tim.Bird@sony.com [mailto:Tim.Bird@sony.com]
> > >
> > > Perhaps, the best would be to talk with the upstream developers and see
> if
> > > they would
> > > accept a patch that uses a different argument parser.
> > > What do you think?
> >
> > if popt is no longer maintained, it will be increasingly difficult to obtain
> > or see pre-integrated into toolchains and SDKs.  I think the approach
> > of removing the dependency from dbench is best.
> 
> That's what I meant by replacing it with a different argument parser.
> Do you prefer doing it as a patch, or upstream?

upstream is preferred.  But if they won't take it a patch would be good.
 -- Tim

Re: [Fuego] dbench no longer builds on any of my boards

[Daniel Sangorrin]

> -----Original Message-----
> From: Tim.Bird@sony.com [mailto:Tim.Bird@sony.com]
> Sent: Tuesday, March 27, 2018 11:57 AM
> > > if popt is no longer maintained, it will be increasingly difficult to obtain
> > > or see pre-integrated into toolchains and SDKs.  I think the approach
> > > of removing the dependency from dbench is best.
> >
> > That's what I meant by replacing it with a different argument parser.
> > Do you prefer doing it as a patch, or upstream?
> 
> upstream is preferred.  But if they won't take it a patch would be good.

Just an status update. I managed to substitute popt by argp.
However I have found other problems and cross-compiling issues with the test.
Maybe for this release we can stick to the previous dbench.

Thanks,
Daniel

Re: [Fuego] dbench no longer builds on any of my boards

[Daniel Sangorrin]

> -----Original Message-----
> From: Tim.Bird@sony.com [mailto:Tim.Bird@sony.com]
> > -----Original Message-----
> > From: Daniel Sangorrin
> > > -----Original Message-----
> > > From: Tim.Bird@sony.com
> 
> > > Sent: Tuesday, March 27, 2018 11:57 AM
> > > > > if popt is no longer maintained, it will be increasingly difficult to obtain
> > > > > or see pre-integrated into toolchains and SDKs.  I think the approach
> > > > > of removing the dependency from dbench is best.
> > > >
> > > > That's what I meant by replacing it with a different argument parser.
> > > > Do you prefer doing it as a patch, or upstream?
> > >
> > > upstream is preferred.  But if they won't take it a patch would be good.
> >
> > Just an status update. I managed to substitute popt by argp.
> > However I have found other problems and cross-compiling issues with the
> > test.
> > Maybe for this release we can stick to the previous dbench.
> 
> OK - thanks for working on this.

One more update.

I completed the port to argp and solved a few other cross-compiling issues.
Currently, those changes (5 commits) are waiting for review at Sahlberg's pull queue.
https://github.com/sahlberg/dbench/pull/5

In the latest version of dbench they have included yet a new dependency though. This
time is zlib1g-dev (-lz). Do you think it is reasonable to ask users to have this dependency?
One alternative is to conserve the two versions of dbench in separate directories (dbench3 and
dbench4).

Regards,
Daniel

Re: [Fuego] dbench no longer builds on any of my boards

[Tim.Bird]

> -----Original Message-----
> From: Daniel Sangorrin 
> > -----Original Message-----
> > From: Tim.Bird@sony.com [mailto:Tim.Bird@sony.com]
> > > -----Original Message-----
> > > From: Daniel Sangorrin
> > > > -----Original Message-----
> > > > From: Tim.Bird@sony.com
> >
> > > > Sent: Tuesday, March 27, 2018 11:57 AM
> > > > > > if popt is no longer maintained, it will be increasingly difficult to
> obtain
> > > > > > or see pre-integrated into toolchains and SDKs.  I think the approach
> > > > > > of removing the dependency from dbench is best.
> > > > >
> > > > > That's what I meant by replacing it with a different argument parser.
> > > > > Do you prefer doing it as a patch, or upstream?
> > > >
> > > > upstream is preferred.  But if they won't take it a patch would be good.
> > >
> > > Just an status update. I managed to substitute popt by argp.
> > > However I have found other problems and cross-compiling issues with
> the
> > > test.
> > > Maybe for this release we can stick to the previous dbench.
> >
> > OK - thanks for working on this.
> 
> One more update.
> 
> I completed the port to argp and solved a few other cross-compiling issues.
> Currently, those changes (5 commits) are waiting for review at Sahlberg's pull
> queue.
> https://github.com/sahlberg/dbench/pull/5
> 
> In the latest version of dbench they have included yet a new dependency
> though. This
> time is zlib1g-dev (-lz). Do you think it is reasonable to ask users to have this
> dependency?

It's been in Debian since wheezy, so it's not an uncommon library, from what I
can tell.  But the safest thing, from a long-term standpoint, is to just include
a libz tarball in the dbench package, and build it with dbench.  A tarball is available
here, http://zlib.net/zlib-1.2.11.tar.gz
and it's small (under 600k) and builds easily.

> One alternative is to conserve the two versions of dbench in separate
> directories (dbench3 and dbench4)

That's a pretty good strategy for any time we have packages transitioning
between versions, and there are substantive difference that might break
the tests for different user/platforms.

 -- Tim

Re: [Fuego] dbench no longer builds on any of my boards

[Tim.Bird]

> -----Original Message-----
> From: Daniel Sangorrin 
> > -----Original Message-----
> > From: Tim.Bird@sony.com [mailto:Tim.Bird@sony.com]
> > > -----Original Message-----
> > > From: Daniel Sangorrin
> > > > -----Original Message-----
> > > > From: Tim.Bird@sony.com
> >
> > > > Sent: Tuesday, March 27, 2018 11:57 AM
> > > > > > if popt is no longer maintained, it will be increasingly difficult to
> obtain
> > > > > > or see pre-integrated into toolchains and SDKs.  I think the approach
> > > > > > of removing the dependency from dbench is best.
> > > > >
> > > > > That's what I meant by replacing it with a different argument parser.
> > > > > Do you prefer doing it as a patch, or upstream?
> > > >
> > > > upstream is preferred.  But if they won't take it a patch would be good.
> > >
> > > Just an status update. I managed to substitute popt by argp.
> > > However I have found other problems and cross-compiling issues with
> the
> > > test.
> > > Maybe for this release we can stick to the previous dbench.
> >
> > OK - thanks for working on this.
> 
> One more update.
> 
> I completed the port to argp and solved a few other cross-compiling issues.
> Currently, those changes (5 commits) are waiting for review at Sahlberg's pull
> queue.
> https://github.com/sahlberg/dbench/pull/5
That's great!  It's really useful to have this stuff submitted upstream.

Thanks!
 -- Tim

Re: [Fuego] dbench no longer builds on any of my boards

[Daniel Sangorrin]

> -----Original Message-----
> From: Tim.Bird@sony.com [mailto:Tim.Bird@sony.com]
> Sent: Saturday, March 31, 2018 1:35 AM
> To: daniel.sangorrin@toshiba.co.jp
> Cc: fuego@lists.linuxfoundation.org
> Subject: RE: [Fuego] dbench no longer builds on any of my boards
> 
> 
> 
> > -----Original Message-----
> > From: Daniel Sangorrin
> > > -----Original Message-----
> > > From: Tim.Bird@sony.com [mailto:Tim.Bird@sony.com]
> > > > -----Original Message-----
> > > > From: Daniel Sangorrin
> > > > > -----Original Message-----
> > > > > From: Tim.Bird@sony.com
> > >
> > > > > Sent: Tuesday, March 27, 2018 11:57 AM
> > > > > > > if popt is no longer maintained, it will be increasingly difficult to
> > obtain
> > > > > > > or see pre-integrated into toolchains and SDKs.  I think the approach
> > > > > > > of removing the dependency from dbench is best.
> > > > > >
> > > > > > That's what I meant by replacing it with a different argument parser.
> > > > > > Do you prefer doing it as a patch, or upstream?
> > > > >
> > > > > upstream is preferred.  But if they won't take it a patch would be good.
> > > >
> > > > Just an status update. I managed to substitute popt by argp.
> > > > However I have found other problems and cross-compiling issues with
> > the
> > > > test.
> > > > Maybe for this release we can stick to the previous dbench.
> > >
> > > OK - thanks for working on this.
> >
> > One more update.
> >
> > I completed the port to argp and solved a few other cross-compiling issues.
> > Currently, those changes (5 commits) are waiting for review at Sahlberg's pull
> > queue.
> > https://github.com/sahlberg/dbench/pull/5
> >
> > In the latest version of dbench they have included yet a new dependency
> > though. This
> > time is zlib1g-dev (-lz). Do you think it is reasonable to ask users to have this
> > dependency?
> 
> It's been in Debian since wheezy, so it's not an uncommon library, from what I
> can tell.  But the safest thing, from a long-term standpoint, is to just include
> a libz tarball in the dbench package, and build it with dbench.  A tarball is available
> here, http://zlib.net/zlib-1.2.11.tar.gz
> and it's small (under 600k) and builds easily.
> 
> > One alternative is to conserve the two versions of dbench in separate
> > directories (dbench3 and dbench4)
> 
> That's a pretty good strategy for any time we have packages transitioning
> between versions, and there are substantive difference that might break
> the tests for different user/platforms.

OK, I will do both.
By the way, my patches were merged upstream so I will prepare a tarball from the latest commit.
https://github.com/sahlberg/dbench/pull/5

Thanks,
Daniel