[LEDE-DEV,1/2] Add some common packages for x86-64 target.

From: Ben Greear <greearb@candelatech.com>

This should make x86-64 targets more useable out of the box.
The assumption is that most x86-64 users have adequate storage,
and those that do not can still config away the options they
do not need.

Signed-off-by: Ben Greear <greearb@candelatech.com>
---
 target/linux/x86/64/target.mk | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

Hi,

On Thu, 2016-05-26 at 16:57 -0700, greearb@candelatech.com wrote: 
> From: Ben Greear <greearb@candelatech.com>
> 
> This should make x86-64 targets more useable out of the box.
> The assumption is that most x86-64 users have adequate storage,
> and those that do not can still config away the options they
> do not need.

Although I agree x86-64 is normally big, I'm not sure that it makes
sense to make the default install so different from other devices.  One
thing you might want to look is that patch series I've got as URFC's for
doing things like preferring full vs. busybox and see if you could
implement this as something that could be added via a single package
install (or from imagebuilder baked into the image by specifying a
single package).

I'm not sure that making big/extra/different stuff part of snapshot and
release images is a good idea (although including more drivers is
different IMO, because that is about hardware support out of the box,
rather than about different choices about what's in the OS (unlike full
bzip2, getopt, different busybox options, etc)).  I think the user should
consciously decide they're looking for something other than a standard
LEDE system.

Regards,

Daniel

>> This should make x86-64 targets more useable out of the box.
>> The assumption is that most x86-64 users have adequate storage,
>> and those that do not can still config away the options they
>> do not need.
 
> Although I agree x86-64 is normally big, I'm not sure that it makes
> sense to make the default install so different from other devices.

I agree. I use the x86-64 build as a baseline for virtualized servers. I
very much value that I can trust that these distributions arrive about
as minimal as possible. Obviously, I add a number of packages, but the
nice thing is that I am in complete control of what I end up with.
There was a time when it was commonly possible to look at a computer
and examine every piece of software installed and each configuration
file used; with OpenWrt/LEDE I am glad this is largely still the case.

On 05/26/2016 07:05 PM, Daniel Curran-Dickinson wrote:
>
> Hi,
>
> On Thu, 2016-05-26 at 16:57 -0700, greearb@candelatech.com wrote:
>> From: Ben Greear <greearb@candelatech.com>
>>
>> This should make x86-64 targets more useable out of the box.
>> The assumption is that most x86-64 users have adequate storage,
>> and those that do not can still config away the options they
>> do not need.
>
> Although I agree x86-64 is normally big, I'm not sure that it makes
> sense to make the default install so different from other devices.  One
> thing you might want to look is that patch series I've got as URFC's for
> doing things like preferring full vs. busybox and see if you could
> implement this as something that could be added via a single package
> install (or from imagebuilder baked into the image by specifying a
> single package).
>
> I'm not sure that making big/extra/different stuff part of snapshot and
> release images is a good idea (although including more drivers is
> different IMO, because that is about hardware support out of the box,
> rather than about different choices about what's in the OS (unlike full
> bzip2, getopt, different busybox options, etc)).  I think the user should
> consciously decide they're looking for something other than a standard
> LEDE system.

So maybe getopt is not needed, but here is my reasoning for some of the
others:

tcpdump:  Grab pkt captures, especially in monitor mode for debugging.
           Pkt capture is pretty much required for debugging tricky things, especially
           with something like ath10k that has thick firmware.
ethtool:  Low level stats, firmware version, etc.  Automated bug reporting.
lspci: Automated bug reporting, figure out what driver is missing from random hardware.
curl:  Download scripts and other things from the web, including in automated fashion.
iw:  Automated bug reporting, manual debugging.
iperf3:  Easy way to do performance testing.  Could be part of automated performance testing.

I think if space allows, these should be added to all or most images,
but I wanted to start with a platform that I use and can test, and which
has no space constraints in most cases.  So, this more full image could
start being more the 'standard LEDE' system.

I can do this all with the buildme logic in my 2/2 patch too, so maybe that
is the way to go.

Thanks,
Ben

Hi Ben,

i am inclined to reject this one. i understand the reasoning behind the
patch but the general concept is to keep images minimal. the tools might
make sense to you for your use case but others will want a different
selection of tools/drivers. we will never be able to find a set suitable
for everyone which is why it was decided ages ago to keep the list minimal.

	John

On 27/05/2016 01:57, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
> 
> This should make x86-64 targets more useable out of the box.
> The assumption is that most x86-64 users have adequate storage,
> and those that do not can still config away the options they
> do not need.
> 
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
>  target/linux/x86/64/target.mk | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/target/linux/x86/64/target.mk b/target/linux/x86/64/target.mk
> index 6497698..95bd378 100644
> --- a/target/linux/x86/64/target.mk
> +++ b/target/linux/x86/64/target.mk
> @@ -1,6 +1,14 @@
>  ARCH:=x86_64
>  BOARDNAME:=x86_64
> -DEFAULT_PACKAGES += kmod-button-hotplug kmod-e1000e kmod-e1000 kmod-r8169
> +DEFAULT_PACKAGES += kmod-button-hotplug kmod-e1000e kmod-e1000 kmod-r8169 kmod-8139cp kmod-8139too
> +DEFAULT_PACKAGES += kmod-i2c-core kmod-i2c-algo-bit kmod-igb
> +# Add some drivers for common wifi NICs
> +DEFAULT_PACKAGES += kmod-ath9k kmod-ath10k kmod-ath9k-htc kmod-ath5k
> +# Add some firmware
> +DEFAULT_PACKAGES += ath10k-firmware-qca988x ath10k-firmware-qca99x0 ath9k-htc-firmware ath10k-firmware-qca6174
> +# Useful general OS packages
> +DEFAULT_PACKAGES += bzip2 curl dmesg ethtool getopt hostapd ip-full iperf3 iputils-ping iputils-tracepath iw
> +DEFAULT_PACKAGES += nstat relayd tcpdump wpa-cli wpa-supplicant wpa-supplicant-mesh
>  
>  define Target/Description
>          Build images for 64 bit systems including virtualized guests.
>

To fork this discussion mildly, I would like to see a fuller build,
including the luci gui, available, somehow, somewhere, so that newer
users can get a working config "out of the box" from the daily builds.

Also, at least on the archer c7v2, the ath10k kmod and firmware were
not included in the default build.

On 01/06/2016 20:24, Dave Taht wrote:
> To fork this discussion mildly, I would like to see a fuller build,
> including the luci gui, available, somehow, somewhere, so that newer
> users can get a working config "out of the box" from the daily builds.
> 
> Also, at least on the archer c7v2, the ath10k kmod and firmware were
> not included in the default build.
> 

we are currently adding multiprofile build support. so that a buildjob
will produce images for all profiles with the corresponding default
package selection. i would like to see luci added. that will in effect
be what you just described.

	John

I agree with having somehow a full build available for new users.
Now that "market" seems to be catered by custom images published by some in the Owrt forum and consumed by many who want a better router firmware but don't know how to build it, and most probably don't even want to know or take the time to set up all the environment to just build an image only once to flash the router and forget about it (for all this many end up using other "friendlier" projects, like I did myself for quite some time - without realizing what I was missing!).

As I see it the "buildme" script doesn't address that problem, as you still need to build.

I would take a different approach:

+ for the ones willing to actually build themselves I think than jow's idea of a good "how to" should do
+ for the rest (I'm assuming it's the majority) I would do a "full" or "moded" metapackage for each target with the most important extras (assuming a fair agreement can be reached on which are those).
That way anyone can just flash a nightly build and with just one "opkg" upgrade to a full build, closer to an "out of the box" experience without sacrificing much of the spirit, and with much less need for maintenance, and very little code.

The idea could be further elaborated - and perhaps it already was, and was discarded :).
Factory images (the entry point to LEDE for newcomers) could have at least a basic LUCI so that the "full" opkg installation could be easily done without needing to ssh into the router (in Windows even for that you need to install additional software to your PC).
For sysupgrade, once you are already with LEDE, I would add an option "download and reinstall currently installed packages" to complement the keep settings option. If one wants a really quick upgrade.

Sorry for the long mail. I found Owrt/LEDE a great product and easing its adoption is really worth. 


> El 01/06/2016, a las 1:26 p.m., Dave Taht <dave.taht@gmail.com> escribió:

> 

> To fork this discussion mildly, I would like to see a fuller build,

> including the luci gui, available, somehow, somewhere, so that newer

> users can get a working config "out of the box" from the daily builds.

> 

> Also, at least on the archer c7v2, the ath10k kmod and firmware were

> not included in the default build.

> 

> _______________________________________________

> Lede-dev mailing list

> Lede-dev@lists.infradead.org

> http://lists.infradead.org/mailman/listinfo/lede-dev