IgorS

  • Posts

    70
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

IgorS's Achievements

  1. Oh, that is good. I have one machine which really need kernel update, because it was offline last six months. Thank you very much.
  2. Unfortunatelly i have same situation: igor@ovpngw:~$ sudo apt update [sudo] password for igor: Hit:1 http://ppa.launchpad.net/ultradvorka/ppa/ubuntu bionic InRelease Hit:2 http://ports.ubuntu.com bionic InRelease Hit:4 http://ports.ubuntu.com bionic-security InRelease Hit:5 http://ports.ubuntu.com bionic-updates InRelease Hit:6 http://ports.ubuntu.com bionic-backports InRelease Ign:3 https://armbian.hosthatch.com/apt bionic InRelease Get:7 https://armbian.systemonachip.net/apt bionic Release [17,5 kB] Ign:8 https://armbian.systemonachip.net/apt bionic Release.gpg Reading package lists... Done E: The repository 'http://apt.armbian.com bionic Release' is no longer signed. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. Please, what can I do to fix this (if I can anything at all)?
  3. Yes, I am building current images. 2021-03-27 14:17:03 Executing: ./compile.sh BOARD=orangepione USEALLCORES=yes BRANCH=current KERNEL_ONLY=yes KERNEL_CONFIGURE=no Result: version 5.10.21
  4. Hello Armbian, Since long time ago, build system is stuck at mainline kernel version 5.10.21 (for OrangePi H2+ H3 and H5 boards). Am I doing something wrong or what? Best regards.
  5. Tried, problem is really solved. Btw, I am building kernels for 6 boards, mainline and legacy, everytime when new versions of kernel appear. Changes in building system that have been made since kernel version 5.8.16 speeds up building about 20%, according my observations. Good work!
  6. Of course, I know that debugging takes time. I'm just trying to provide developers with as many clues as I can to make their job easier.
  7. I need to build kernels for several sbcs, six to be exact and do this in a loop using a small script to save myself from waiting build to finish and start another.The reason why I don't want to clear entire cache directory is because in that case it downloads toolchain's and sources again and this is slow. It looks like that deleting 'ghost' debs in build/cache/sources/linux-mainline before building do the magic.
  8. I think, found what is wrong. @Werner was right, first build from 'fresh' build directory is always ok. In next builds without 'radical' cleaning cache things go messy. In directory build/cache/sources/Linux-mainline I found: linux-5.4.72-sunxi_20.11.0-trunk_armhf.buildinfo linux-5.4.72-sunxi_20.11.0-trunk_armhf.changes linux-5.8.17-sunxi64_20.11.0-trunk_arm64.buildinfo linux-5.8.17-sunxi64_20.11.0-trunk_arm64.changes linux-5.8.17-sunxi_20.11.0-trunk_armhf.buildinfo linux-5.8.17-sunxi_20.11.0-trunk_armhf.changes linux-dtb-current-sunxi64_20.11.0-trunk_arm64.deb linux-dtb-current-sunxi_20.11.0-trunk_armhf.deb linux-dtb-legacy-sunxi_20.11.0-trunk_armhf.deb linux-headers-current-sunxi64_20.11.0-trunk_arm64.deb linux-headers-current-sunxi_20.11.0-trunk_armhf.deb linux-headers-legacy-sunxi_20.11.0-trunk_armhf.deb linux-image-current-sunxi64_20.11.0-trunk_arm64.deb linux-image-current-sunxi_20.11.0-trunk_armhf.deb linux-image-legacy-sunxi_20.11.0-trunk_armhf.deb orange-pi-5.4 orange-pi-5.8 I am pretty sure that this *.deb doesn't belong there, so I'll try delete it before each iteration (each board build).
  9. @Werner thanks for advice, but I got a whole bunch of debs at first build, after I deleted build directory and created it fresh from git. It can't be a problem with any 'leftovers' because everything was fresh.
  10. Definitely is an issue. For very long time i use build script to build kernel for several orange pi boards, and allways the result was 8 debs for each board: source, dtb, headers, image, u-boot, armbian-firmware, armbian-firmware-full, armbian-config. Now something went terribly wrong, I become whole bunch of debs which are unrelated to my target.
  11. I can confirm, there is new bug in build system. I tried with clean build system just cloned from git, and here is the result in build/output/debs which was empty (not existing) before build run: 2020-10-31 07:51:45 Executing: ./compile.sh BOARD=orangepione USEALLCORES=yes BRANCH=current KERNEL_ONLY=yes KERNEL_CONFIGURE=no 2020-10-31 08:18:36 Created: file: -rw-r--r-- 1 root root 43716 2020-10-31 08:17:33.152639730 +0100 armbian-config_20.11.0-trunk_all.deb file: -rw-r--r-- 1 root root 139643152 2020-10-31 08:18:35.516980290 +0100 armbian-firmware-full_20.11.0-trunk_all.deb file: -rw-r--r-- 1 root root 6915836 2020-10-31 08:17:44.032001230 +0100 armbian-firmware_20.11.0-trunk_all.deb file: drwxrwsr-x 2 root sudo 4096 2020-10-30 10:23:38.957016051 +0100 extra file: -rw-r--r-- 1 root sudo 77852 2020-10-31 08:17:31.440740205 +0100 linux-dtb-current-sunxi64_20.11.0-trunk_arm64.deb file: -rw-r--r-- 1 root sudo 192228 2020-10-31 08:17:31.400742552 +0100 linux-dtb-current-sunxi_20.11.0-trunk_armhf.deb file: -rw-r--r-- 1 root sudo 58208 2020-10-31 08:17:31.440740205 +0100 linux-dtb-legacy-sunxi64_20.11.0-trunk_arm64.deb file: -rw-r--r-- 1 root sudo 182012 2020-10-31 08:17:31.440740205 +0100 linux-dtb-legacy-sunxi_20.11.0-trunk_armhf.deb file: -rw-r--r-- 1 root sudo 11261392 2020-10-31 08:17:31.488737387 +0100 linux-headers-current-sunxi64_20.11.0-trunk_arm64.deb file: -rw-r--r-- 1 root sudo 11382152 2020-10-31 08:17:31.460739031 +0100 linux-headers-current-sunxi_20.11.0-trunk_armhf.deb file: -rw-r--r-- 1 root sudo 11008696 2020-10-31 08:17:31.544734101 +0100 linux-headers-legacy-sunxi64_20.11.0-trunk_arm64.deb file: -rw-r--r-- 1 root sudo 11089428 2020-10-31 08:17:31.516735744 +0100 linux-headers-legacy-sunxi_20.11.0-trunk_armhf.deb file: -rw-r--r-- 1 root sudo 33151948 2020-10-31 08:17:31.688725650 +0100 linux-image-current-sunxi64_20.11.0-trunk_arm64.deb file: -rw-r--r-- 1 root sudo 35331128 2020-10-31 08:17:31.604730580 +0100 linux-image-current-sunxi_20.11.0-trunk_armhf.deb file: -rw-r--r-- 1 root sudo 34922552 2020-10-31 08:17:31.856715790 +0100 linux-image-legacy-sunxi64_20.11.0-trunk_arm64.deb file: -rw-r--r-- 1 root sudo 34758916 2020-10-31 08:17:31.772720720 +0100 linux-image-legacy-sunxi_20.11.0-trunk_armhf.deb file: -rw-r--r-- 1 root root 403306604 2020-10-31 08:17:29.904830351 +0100 linux-source-current-sunxi_20.11.0-trunk_all.deb file: -rw-r--r-- 1 root root 228852 2020-10-31 07:52:49.533361612 +0100 linux-u-boot-current-orangepione_20.11.0-trunk_armhf.deb 2020-10-31 08:18:36 Built in 0d 0h 26m 51s: orangepione,current
  12. Finally good news! Today (2020-07-14) for ubuntu bionic becomes available mesa update, following packages: libegl-mesa0 libegl1-mesa libgbm1 libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa libglx-mesa0 mesa-va-drivers mesa-vdpau-drivers After that, xfce desktop on orangepi2e starts to work flawlessly with kernel 5.4.xx (in my case 5.4.51) again. Exact versions of packages: igor@orangepiplus2e:~/trash/mesa$ dpkg -l | grep 'mesa\|libgbm1' ii libegl-mesa0:armhf 20.0.8-0ubuntu1~18.04.1 armhf free implementation of the EGL API -- Mesa vendor library ii libegl1-mesa:armhf 20.0.8-0ubuntu1~18.04.1 armhf transitional dummy package ii libgbm1:armhf 20.0.8-0ubuntu1~18.04.1 armhf generic buffer management API -- runtime ii libgl1-mesa-dri:armhf 20.0.8-0ubuntu1~18.04.1 armhf free implementation of the OpenGL API -- DRI modules ii libgl1-mesa-glx:armhf 20.0.8-0ubuntu1~18.04.1 armhf transitional dummy package ii libglapi-mesa:armhf 20.0.8-0ubuntu1~18.04.1 armhf free implementation of the GL API -- shared library ii libglx-mesa0:armhf 20.0.8-0ubuntu1~18.04.1 armhf free implementation of the OpenGL API -- GLX vendor library ii mesa-utils 8.4.0-1 armhf Miscellaneous Mesa GL utilities ii mesa-va-drivers:armhf 20.0.8-0ubuntu1~18.04.1 armhf Mesa VA-API video acceleration drivers ii mesa-vdpau-drivers:armhf 20.0.8-0ubuntu1~18.04.1 armhf Mesa VDPAU video acceleration drivers