• Content Count

  • Joined

  • Last visited

  1. No, this not armbian way - why not add another dialog layer ? It is definitely better for the developers - they are happy to iterate over the same things forever - errors, endless compiles, etc.
  2. No sad here - you just unable to accept the critics. Its dead end. Bye
  3. Yes the room for the improvement can exist only when developers have the clear mind without "f#ck off, it works for me" garbage
  4. It will not work as the single kernel config over the same $LINUXFAMILY assumed that videoadapter must be present. You shoot yourself in the foot...
  5. The project sucks if people need documentation to see the build errors. Sure, the old plain make always rules. Just try to study the Linux kernel build system. It must be set by default. But seems like by default you are more comfortable to hide the build errors. No discussion was made as you are not familiar with simple logic that you have been created by your own for this project. Try to dig in it again: people forced to select the board but not board config (!?) Seems like overbloat is normal for you but not to the rest of the embedded world where every byte has its own weight. So people need the special sorting rule for trying to fix the broken patches ? This is pure sh#t logic. Think a little bit more about moving the userpatches stage after the built-in ones. Try to build custom u-boot with FORCE_CHECKOUT=no in latest git. You even never tested your poor scripts. So my original critic was that these variables are spreaded among several scripts. If you are not able to create the good build system - try at least create the single clear and working config for current one. Do no lie at least here. Re-read the first post of this thread and your first answer. Your first answer about build error was not figuring out its actual cause but bold statement that all is working locally to you. There exist the funny didactic story about fire fighter that is exact same as you: some person called the fire station and crying that his house at fire. But the fire fighter have been answered the following: "I'm having the same house in front of me - and it is all ok wit it." Try to turn by the face not ass to your users and may be you will have some positive feedback. Good bye
  6. It is the worst build system I've ever saw: - bunch of shell scripts with spread out and not documented vars inside - it is hiding build errors by default with useless dialogs - broken overbloat logic where you have to select the board but not its kernel config as appeared that config is silently shared among several boards - no way to apply custom patch _after_ the builtin patch stage - useless for developing as cleans and restarts all the build tree over again - support in term - "it works for us (admins) and we do not care if it do not works for users" Sorry, I do not see how I can use this.
  7. I see So what ? It uses the wrong quotes type which will work only for en_US locale. Seems like not the patch but globe need to be corrected )
  8. If you check echo section in 'man bash' you will find useful the following patch which fixes problem with this buggy patch : .. --- sources/linux-sun8i/sun8i/drivers/gpu/mali/mali/Kbuild.orig 2017-02-24 18:48:09.929512034 +0200 +++ sources/linux-sun8i/sun8i/drivers/gpu/mali/mali/Kbuild 2017-02-24 19:28:26.386511134 +0200 @@ -270,4 +270,4 @@ # Create file with Mali driver configuration $(DRIVER_DIR)/__malidrv_build_info.c: - @echo 'const char *__malidrv_build_info(void) { return "malidrv: $(VERSION_STRINGS)";}' > $(DRIVER_DIR)/__malidrv_build_info.c + @echo "const char *__malidrv_build_info(void) { return \"malidrv: $(VERSION_STRINGS)\";}" > $(DRIVER_DIR)/__malidrv_build_info.c .. It is 'we do not care' like answer. So I think your logic is not consistent. If you state that have the NanoPI Neo board supported and have the actual board config - then follow this logic. Otherwise just remove all the H3 boards and use the generic 'H3' kernel config It is definitely armbian configuration bug that have to be fixed - this board do not have the HDMI or TV out.
  9. ok, the actual error is: ... /bin/sh: 1: Syntax error: Unterminated quoted string /home/rus/Projects/rtpdev/v2/sources/linux-sun8i/sun8i/drivers/gpu/mali/mali/Kbuild:273: recipe for target 'drivers/gpu/mali/mali/__malidrv_build_info.c' failed make[4]: *** [drivers/gpu/mali/mali/__malidrv_build_info.c] Error 2 scripts/Makefile.build:443: recipe for target 'drivers/gpu/mali/mali' failed make[3]: *** [drivers/gpu/mali/mali] Error 2 scripts/Makefile.build:443: recipe for target 'drivers/gpu/mali' failed make[2]: *** [drivers/gpu/mali] Error 2 scripts/Makefile.build:443: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:948: recipe for target 'drivers' failed make: *** [drivers] Error 2 make: *** Waiting for unfinished jobs.... .... And caused by armbian/patch/kernel/sun8i-default/add-mali-r3p0-fixed.patch. The only thing I can't understand beside untested patch - is why to enable the Mali at NanoPi Neo board which do not has any video output ????
  10. Hello, While trying to build full Devian Jessy image for NanoPi Neo at stock x86_64 Ubuntu 16.04 using latest https://github.com/igorpecovnik/libgit , got this: ... [ o.k. ] Compiling default kernel [ 3.4.113 ] [ o.k. ] Compiler version [ arm-linux-gnueabihf-gcc 5.4.0 ] [ o.k. ] Using kernel config file [ lib/config/kernel/linux-sun8i-default.config ] HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.hash.c SHIPPED scripts/kconfig/zconf.lex.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --silentoldconfig Kconfig drivers/net/wireless/bcmdhd/Kconfig:56:warning: defaults for choice values not supported Armbian building script, http://www.armbian.com| Author: Igor Pecovnik ────────────────────────────────────────────────────────────────────────────────────────────────────── ┌────────────────────────────────────────────────────────────────────────────────────────────────┠│ Compiling kernel... │ │────────────────────────────────────────────────────────────────────────────────────────────────│ │ CC [M] net/netfilter/ipvs/ip_vs_wrr.o │ │ CC [M] net/netfilter/ipvs/ip_vs_lc.o │ │ CC [M] net/netfilter/ipvs/ip_vs_wlc.o │ │ CC [M] net/netfilter/ipvs/ip_vs_lblc.o │ │ CC [M] net/netfilter/ipvs/ip_vs_lblcr.o │ │ CC [M] net/netfilter/ipvs/ip_vs_dh.o │ │ CC [M] net/netfilter/ipvs/ip_vs_sh.o │ │ CC [M] net/netfilter/ipvs/ip_vs_sed.o │ │ CC [M] net/netfilter/ipset/ip_set_list_set.o │ │ CC [M] net/netfilter/ipvs/ip_vs_nq.o │ │ LD [M] net/netfilter/ipset/ip_set.o │ │ CC [M] net/netfilter/ipvs/ip_vs_ftp.o │ │ CC [M] net/netfilter/ipvs/ip_vs_pe_sip.o │ │ LD [M] net/netfilter/ipvs/ip_vs.o │ │ LD [M] net/netfilter/nf_conntrack.o │ │ LD net/netfilter/netfilter.o │ │ LD net/netfilter/built-in.o │ │ LD net/built-in.o │ [ error ] ERROR in function compile_kernel [ common.sh:249 ] [ error ] Kernel was not built [ @host ] [ o.k. ] Process terminated .... The full kernel compile error is covered by dialog output so no way (!?) to see it. The question is : how to compile the image without this stupid ncurses dialog - just using plain tty with normal error output ? TIA, Rus