Sfinx Posted February 24, 2017 Posted February 24, 2017 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
Sfinx Posted February 24, 2017 Author Posted February 24, 2017 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 ????
zador.blood.stained Posted February 24, 2017 Posted February 24, 2017 The only thing I can't understand beside untested patch Untested https://github.com/igorpecovnik/lib/blob/master/patch/kernel/sun8i-default/add-mali-r3p0-fixed.patch Last change more than 4 months ago (not counting previous versions), so it worked fine for several releases and tons of nightlies and user builds. is why to enable the Mali at NanoPi Neo board which do not has any video output ???? Because the kernel configuration is the same for all H3 based boards, and FEX configuration (in case of the legacy kernel) and /etc/modules contents define what is actually used on different hardware. /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 If you check the Kbuild file that produces this error, you'll see that it collects some info about build machine and build configuration (including date, CPU type, configuration name, ...), so something inserts unterminated or unescaped quote, which breaks the build process for you. This didn't happen for anybody before (at least there were no reports of build breakages for this particular reason).
Sfinx Posted February 24, 2017 Author Posted February 24, 2017 Untested https://github.com/igorpecovnik/lib/blob/master/patch/kernel/sun8i-default/add-mali-r3p0-fixed.patch Last change more than 4 months ago (not counting previous versions), so it worked fine for several releases and tons of nightlies and user builds. Because the kernel configuration is the same for all H3 based boards, and FEX configuration (in case of the legacy kernel) and /etc/modules contents define what is actually used on different hardware. If you check the Kbuild file that produces this error, you'll see that it collects some info about build machine and build configuration (including date, CPU type, configuration name, ...), so something inserts unterminated or unescaped quote, which breaks the build process for you. This didn't happen for anybody before (at least there were no reports of build breakages for this particular reason). 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 .. Because the kernel configuration is the same for all H3 based boards, and FEX configuration (in case of the legacy kernel) and /etc/modules contents define what is actually used on different hardware. 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.
tkaiser Posted February 24, 2017 Posted February 24, 2017 It is definitely armbian configuration bug that have to be fixed - this board do not have the HDMI or TV out. OMFG! Check Armbian documentation how to prevent this patch that causes troubles on your machine from being applied (empty file with same name in appropriate userpatches dir). Be assured that we will still use one single kernel config and one set of patches per $LINUXFAMILY in the future. And please try to understand Zador's answer regarding 'FEX configuration (in case of the legacy kernel) and /etc/modules contents'. Thanks!
zador.blood.stained Posted February 24, 2017 Posted February 24, 2017 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. So what next? Will you ask Debian or Ubuntu maintainers to disable Nvidia GPUs support in the future because your build host uses AMD GPU or something similar? Armbian kernel package in question is called linux-image-sun8i and kernel configuration is called linux-sun8i-default, so it applies to all devices that use SoC of sun8i family (in Armbian legacy kernel case this includes only H3 SoC). Having per-board compile time kernel config is something that I can't imagine even for a bad dream scenario, since per-board differences can be solved at runtime and the only "disadvantage" is a small amount of wasted disk space. Also nobody prevents you from building a minimal kernel for yourself - that's what Armbian build system is for, and any problems with the build can be solved without questioning release scheme. If you check echo section in 'man bash' you will find useful the following patch which fixes problem with this buggy patch This "buggy patch" is Mali Utgard kernel driver imported without significant changes to the build process.
Sfinx Posted February 24, 2017 Author Posted February 24, 2017 Armbian kernel package in question is called linux-image-sun8i and kernel configuration is called linux-sun8i-default, so it applies to alldevices that use SoC of sun8i family (in Armbian legacy kernel case this includes only H3 SoC) I see This "buggy patch" is Mali Utgard kernel driver imported without significant changes to the build process. 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 )
zador.blood.stained Posted February 24, 2017 Posted February 24, 2017 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 ) Well, now that we know that this may cause build issues, we can just remove this "build info" or make it static. And regarding 'man bash' - /bin/sh in Ubuntu by default is linked to dash, not bash, and dash may have different quotes processing logic.
Sfinx Posted February 25, 2017 Author Posted February 25, 2017 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.
Igor Posted February 25, 2017 Posted February 25, 2017 It is the worst build system I've ever saw: And the only one? I am sure there is room for improvement, but just don't expect that you will jump on experienced developer level in one day. This script become complex if you go out of default zone. This build system is used by us on daily basis and there more and more 3rd party users who are using it for their purpose. If something goes wrong, we fix it or they fix it - with specific fixes, since saying "this script sux" is useless information. Sorry, I do not see how I can use this. Feel free to use and compare to alternative solution if you make them work http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=2451&extra= http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=394
zador.blood.stained Posted February 25, 2017 Posted February 25, 2017 It is the worst build system I've ever saw I have a feeling you didn't find the build system documentation (it is linked on the bottom the project page) if you are asking following questions - bunch of shell scripts with spread out and not documented vars inside I'm assuming you have a better alternative in mind for such a project? - it is hiding build errors by default with useless dialogs PROGRESS_DISPLAY=plain - 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 comments, was discussed above - no way to apply custom patch _after_ the builtin patch stage Patches are applied in order based on their file name (LC_ALL=C sort order). Do I need to explain further how to make your patch apply after the builtin ones? - useless for developing as cleans and restarts all the build tree over again If only there were variables like CLEAN_LEVEL, FORCE_CHECKOUT and KERNEL_KEEP_CONFIG that control this behavior... - support in term - "it works for us (admins) and we do not care if it do not works for users" I don't know what kind of support are you expecting. Using telepathy or similar skills to find out what produces extra quote in your environment?
Sfinx Posted February 27, 2017 Author Posted February 27, 2017 I have a feeling you didn't find the build system documentation (it is linked on the bottom the project page) if you are asking following questions The project sucks if people need documentation to see the build errors. I'm assuming you have a better alternative in mind for such a project? Sure, the old plain make always rules. Just try to study the Linux kernel build system. PROGRESS_DISPLAY=plain It must be set by default. But seems like by default you are more comfortable to hide the build errors. No comments, was discussed above 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. Patches are applied in order based on their file name (LC_ALL=C sort order). Do I need to explain further how to make your patch apply after the builtin ones? 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. If only there were variables like CLEAN_LEVEL, FORCE_CHECKOUT and KERNEL_KEEP_CONFIG that control this behavior... 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. I don't know what kind of support are you expecting. Using telepathy or similar skills to find out what produces extra quote in your environment? 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
Sfinx Posted February 27, 2017 Author Posted February 27, 2017 OMFG! Check Armbian documentation how to prevent this patch that causes troubles on your machine from being applied (empty file with same name in appropriate userpatches dir). Be assured that we will still use one single kernel config and one set of patches per $LINUXFAMILY in the future. And please try to understand Zador's answer regarding 'FEX configuration (in case of the legacy kernel) and /etc/modules contents'. Thanks! 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...
Sfinx Posted February 27, 2017 Author Posted February 27, 2017 And the only one? I am sure there is room for improvement, but just don't expect that you will jump on experienced developer level in one day. This script become complex if you go out of default zone. This build system is used by us on daily basis and there more and more 3rd party users who are using it for their purpose. If something goes wrong, we fix it or they fix it - with specific fixes, since saying "this script sux" is useless information. Feel free to use and compare to alternative solution if you make them work http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=2451&extra= http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=394 Yes the room for the improvement can exist only when developers have the clear mind without "f#ck off, it works for me" garbage
tkaiser Posted February 27, 2017 Posted February 27, 2017 Good bye Bye bye! It's soooo sad to loose such a genius like you trying so hard to improve things with constructive criticism but unfortunately we can't do better! It's our fault since we're way too stupid for our shitty scripts and this world in general (same applies to all other satisfied users of Armbian's build system for sure) but we're not able to realize this since we're suffering from Dunning-Kruger syndrome (we're too stupid to realize how stupid we are -- fantastic, isn't it?! You might visit youtube and let explain that to you by John Cleese)
tkaiser Posted February 27, 2017 Posted February 27, 2017 @Igor, @zador, I second the suggestion to make 'PROGRESS_DISPLAY=plain' the default (I use this all the time myself, we might check our usual invocation of compile.sh to overthink some other defaults too)
Sfinx Posted February 27, 2017 Author Posted February 27, 2017 Bye bye! It's soooo sad to loose such a genius like you trying so hard to improve things with constructive criticism but unfortunately we can't do better! It's our fault since we're way too stupid for our shitty scripts and this world in general (same applies to all other satisfied users of Armbian's build system for sure) but we're not able to realize this since we're suffering from Dunning-Kruger syndrome (we're too stupid to realize how stupid we are -- fantastic, isn't it?! You might visit youtube and let explain that to you by John Cleese) No sad here - you just unable to accept the critics. Its dead end. Bye
Sfinx Posted February 27, 2017 Author Posted February 27, 2017 @Igor, @zador, I second the suggestion to make 'PROGRESS_DISPLAY=plain' the default (I use this all the time myself, we might check our usual invocation of compile.sh to overthink some other defaults too) 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.
Recommended Posts