Jump to content

schwar3kat

Moderators
  • Posts

    241
  • Joined

  • Last visited

Reputation Activity

  1. Like
    schwar3kat reacted to Werner in Developer meeting 9/7/2023   
    https://fi.mirror.armbian.de/.meeting/devmeeting_2023-09-06T17_46_27.885Z-subbed.mp4
  2. Like
    schwar3kat reacted to Werner in Armbian developers meeting 7/26/2023   
    There are and they are stored here unless it is forgotten to record: https://fi.mirror.armbian.de/.meeting
     
    Once you RSVP the link will direct to the meeting. No further instructions needed.
  3. Like
    schwar3kat reacted to Nicholay Riviera in [GUIDE] Kodi on Orange Pi 5 with GPU Hardware Acceleration and HDMI Audio   
    Thank you very much for this info schwar3kat!
  4. Like
    schwar3kat reacted to amazingfate in Kodi for rk35xx 5.10 legacy kernel   
    @schwar3katI'm using kernel 5.10.160-rk35xx kernel now. And I can see wideviine is detected on website https://bitmovin.com/demos/drm by chromium.
    From chrome://components/ I can see widevine is enabled.
    I haven't tried kodi.
  5. Like
    schwar3kat reacted to rlyon in Web site Links   
    Having used YOCTO for a couple of years at work I assumed that creating my own Armbian image was going to be difficult. However to my suprise I was able to create a Bullseye image for the Orange Pi R1+ LTS in less than 1 hour. And, .... it actually runs correctly on the target board. That is pretty good.
  6. Like
    schwar3kat got a reaction from Igor in Armbian 23.05 (Suni) Testings   
    - Orange Pi PC
    - Pine64
    Images boot (xfce_desktop), network connection functions (iperf3). USB ports function, HDMI video and audio work.
  7. Like
    schwar3kat got a reaction from rpardini in armbian-next development   
    I couldn't reproduce the problem, after deleting `cache/tools/oras`, even with CLEAN_LEVEL=debs ARTIFACT_IGNORE_CACHE=yes.
    I deleted the whole cache and was able to reproduce it.
    EDIT:  deleting cache/tools/oras. does reproduce the error.  Not sure why I didn't get the same result earlier.

    https://github.com/armbian/build/issues/4889
  8. Like
    schwar3kat got a reaction from rpardini in armbian-next development   
    https://github.com/armbian/build/issues/4879
  9. Like
    schwar3kat got a reaction from Werner in armbian-next development   
    @rpardini
    Next/main. Creating patches.
     
    When I create a patch with armbian/build master (deprecated) using  CREATE_PATCHES=yes, I get a patch in the output/patch folder in mbox format.
    When I create a patch with armbian/build main using  CREATE_PATCHES=yes ARTIFACT_IGNORE_CACHE=yes, I only get a diff file in the output/patch folder.

    Is this intentional, a bug, or have I perhaps not set something up?  Can I get a mbox patch?
  10. Like
    schwar3kat got a reaction from Igor in Armbian 23.02 (Quoll) Testings   
    Orangepi-r1 tested success:
    Armbian_23.02.1_Orangepi-r1_bullseye_current_5.15.93.img.xz
    Armbian_23.02.1_Orangepi-r1_bullseye_current_5.15.93_minimal.img.xz
    Armbian_23.02.1_Orangepi-r1_jammy_current_5.15.93.img.xz
     
    All images tested and working as expected.
    Iperf performance is as expected in both directions on both ethernet ports simultaneously.
    Wifi works.
    2 images listed on RC testing form (minimal build left off).
  11. Like
    schwar3kat got a reaction from Igor in Armbian 23.02 (Quoll) Testings   
    Orangepizeroplus tested success:
    Armbian_23.02.1_Orangepizeroplus_bullseye_current_5.15.93.img.xz
    Armbian_23.02.1_Orangepizeroplus_bullseye_current_5.15.93_minimal.img.xz
    Armbian_23.02.1_Orangepizeroplus_jammy_current_5.15.93.img.xz
     
    All images tested and working as expected.
    Iperf performance is as expected in both directions on ethernet and wifi ports simultaneously.
    2 images listed on RC testing form (minimal build left off).
  12. Like
    schwar3kat got a reaction from Igor in Armbian 23.02 (Quoll) Testings   
    Orangepi-r1plus-lts tested success:
    Armbian_23.02.1_Orangepi-r1plus-lts_bullseye_current_5.15.93.img.xz
    Armbian_23.02.1_Orangepi-r1plus-lts_bullseye_current_5.15.93_minimal.img.xz
    Armbian_23.02.1_Orangepi-r1plus-lts_jammy_current_5.15.93.img.xz

    All images tested and working as expected. 
    Iperf performance is as expected in both directions on both ports simultaneously.
    2 images listed on RC testing form (minimal build left off).
  13. Like
    schwar3kat reacted to rpardini in armbian-next development   
    Yep, I worked on that a few months ago. We've something like `./compile.sh distccd` which starts a distcc daemon, complete with zeroconf etc, using the same toolchains Armbian would.
    Something else (forget what) enables it to be used on a controller node. You do need a bigger controller machine, say 8-cores, to completely max out some two/three 4-core distccd's, due to the high preprocessing load.
    The network between the machines has to be very good, too (gigabit+). All in all is a "fun" way to use all those SBCs laying around doing nothing, but don't expect something miraculous...
    One day I'll finish / document this...
     
  14. Like
    schwar3kat reacted to SteeMan in armbianEnv.txt should be loaded when booted?   
    I would recommend that you first start with a pre-built image (https://www.armbian.com/orange-pi-pc) Then if you want use the armbian build system (https://docs.armbian.com/Developer-Guide_Build-Preparation/)
    Then you might be able to track down why the Debos isn't working as you think it should. 
  15. Like
    schwar3kat got a reaction from Werner in Armbian don’t boot in orangePi r1 plus lts   
    Hi Namexx
     
    If you have anything plugged into the USB port, try it without.

    There are some home  routers that only do IPv4 some are known to cause issues if IPv6 is enabled.
    If you are on  network using IPv4 then you can try adding a line into /boot/armbianEnv.txt
    extraargs="ipv6.disable=1"

    I'm traveling at present, but when I get home, I will download an image and test on my board.  
    Which image are you using, and how are you flashing it to SD card?

    I tested the current build successfully when it was released, but it's always possible that something has gone wrong since then.

    Edit:  I was very lucky and got an earlier flight.  I should be back home about one or two hours.

    https://docs.armbian.com/User-Guide_Basic-Troubleshooting/
  16. Like
    schwar3kat reacted to rpardini in armbian-next development   
    Yeah, parsing the patches includes being able to decode them.
    Patches should match the encoding of the target patched source; In this case, it's UTF-8.
    In my view, those patches are mangled (not just "in big5"): the original encoding was lost due to copy/pasting, and they're already (in master) putting frakked up characters in the source code.
    So it can't get worse, but now I warn you about the error.
     
     
  17. Like
    schwar3kat reacted to going in Armbian developers meeting 1/11/2023   
    What I am observing here is not a lack of support for this particular armhf architecture.
    This is an incorrectly constructed construction algorithm in the assembly system itself.
    The analysis of the architecture that needs to be built and the architecture on which the build system started working looks pretty trivial and it already exists.
    To do this analysis and upload only what is required for this task does not look like something complicated.

    P.S. This also applies to the master.
  18. Like
    schwar3kat got a reaction from rpardini in Armbian developers meeting 1/11/2023   
    @rpardini one of the actions on the slides: "testing on other architectures (armhf, riscv64)"

     😀 For a lark, I thought I would give it a try on armhf, seeing as I have access to an orangepi-pc running Armbian Jammy
    I mounted an external drive on it.
    Armbian-next build was not successful, and because I don't think that armhf is a significant option, I didn't try too hard but here are the results. 
    I suspect that the gcc-riscv64-linux-gnu package could be excluded if not cross compiling to riskv64, but I didn't investigate further.

    First, I tried the same method that  I used on Intel, and it failed:
    [🌱] Preparing [ host ]
    [🌿] Please read documentation to set up proper compilation environment
    [🌿] https://www.armbian.com/using-armbian-tools/
    [💥] error: Running this tool on non x86_64 or arm64 build host is not supported  [  in prepare_host() at /mnt/storage/armbian-build/armbian-next/build/lib/functions/host/prepare-host.sh:63 ]
    [💥] Build terminating... wait for cleanups...

    I added this into lib/functions/host/prepare-host.sh at line 60 to include armhf in the permitted architectures:
        elif [[ $(dpkg --print-architecture) == armhf ]]; then
            :

    Native build failed again:
    [👉]    Package gcc-riscv64-linux-gnu is not available, but is referred to by another package.
    [👉]    This may mean that the package is missing, has been obsoleted, or
    [👉]    is only available from another source
    [👉]    E: Package 'gcc-riscv64-linux-gnu' has no installation candidate
    [👉]    --> 🧽   28: 13096 - 13096 - 13096: hBE: trap: main_trap_handler [ ERR and 100 trap_manager_error_handled: short_stack:/mnt/storage/armbian-build/armbian-next/build/lib/functions/logging/runners.sh:186 ]

    I installed docker:
    Docker build failed for the same reason:
    [👉]    Get:18 http://ports.ubuntu.com/ubuntu-ports jammy-security/universe armhf Packages [491 kB]
    ...
    [👉]    Package gcc-riscv64-linux-gnu is not available, but is referred to by another package.
    [👉]    This may mean that the package is missing, has been obsoleted, or
    [👉]    is only available from another source
    [👉]    E: Package 'gcc-riscv64-linux-gnu' has no installation candidate
  19. Like
    schwar3kat got a reaction from rpardini in armbian-next development   
    @rpardini armbian-next - repeat build string at the end of the build process leaves out build options, BOARD=...
    and NO_APT_CACHER=... (although armbian build master also leaves out NO_APT_CACHER ) and possibly others.

    I would probably expect that all defined options would be included?

    Original test build string (with desktop and base configuration selected through dialog):
    ./compile.sh BOARD=pine64 BRANCH=current RELEASE=jammy BUILD_MINIMAL=no BUILD_DESKTOP=yes KERNEL_CONFIGURE=no CREATE_PATCHES=no NO_APT_CACHER=yes
     
    Repeat build string returned at the end of the build process ("BOARD=pine64" and "NO_APT_CACHER=yes" are missing):
    [✨] Repeat Build Options [ ./compile.sh   BRANCH=current RELEASE=jammy BUILD_MINIMAL=no BUILD_DESKTOP=yes KERNEL_ONLY=no KERNEL_CONFIGURE=no DESKTOP_ENVIRONMENT=xfce DESKTOP_ENVIRONMENT_CONFIG_NAME=config_base DESKTOP_APPGROUPS_SELECTED="3dsupport browsers chat desktop_tools editors email internet multimedia office programming remote_desktop" COMPRESS_OUTPUTIMAGE=sha,gpg,img ]

    I would also not expect COMPRESS_OUTPUTIMAGE=sha,gpg,img to be included (although no harm in including it).
  20. Like
    schwar3kat got a reaction from rpardini in armbian-next development   
    @rpardini When a file has been changed in the local branch being built then master armbian-build provides a useful warning about not being able to update with a dialog to abort, continue or view changes before building.  

    Personally I find this function to be a very useful reminder and would like to see it in armbian-next.
  21. Like
    schwar3kat reacted to rpardini in armbian-next development   
    Hmm, I don't think I changed anything regarding this -- yet.
    Currently the patches-hash and the real (6.1.3 etc) version of the kernel is not included in the deb filename/version. (it's static, "trunk123" or "23.02" etc).
    And if the deb already exists, the build is skipped.
    Hopefully soon we will include the patches-hash and the kernel version in the deb/filename, so the build detects the .deb is out of date and builds again.
  22. Like
    schwar3kat got a reaction from atone in armbian-next development   
    Thanks for the effort Ricardo.
    I'm not sure that accommodating is perhaps the best option. 
    Just change supported versions should do the trick.
    If the versions supported did not include una then users would know to upgrade.

    I will test your changes but then I should probably upgrade to 21.1 vera.
  23. Like
    schwar3kat got a reaction from atone in armbian-next development   
    When I try this build for a Rockchip64 board orangepi-r1plus-lts, a lot of patches including one of mine produce an error:
    "patch is not properly mbox-formatted".  I guess that checking has become more strict? 
    I don't see a log with patch errors, making it difficult to know what is wrong. 
     
  24. Like
    schwar3kat got a reaction from alex9534126 in Docker fails on Tinkerboard   
    I don't know if this will work and I can't test because I don't have your board.  

    From a different OS same error:
    https://my-take-on.tech/2021/05/07/fix-docker-cgroup-errors-after-systemd-248-update/
    The write-up indicates that might only affect old docker containers, so the possible fix below may only work for those containers.

    To do the same thing in Armbian:
    In /boot/armbianEnv.txt    add a line (or if extraargs already exists add an extra argument separated by a comma)
    extraargs="systemd.unified_cgroup_hierarchy=0"

    Reboot and try again. Good luck.

    Let us know the outcome either way.

    Edit:  great this worked for Walden.
  25. Like
    schwar3kat reacted to Walden in Docker fails on Tinkerboard   
    IT WORKED!!!
     
    Thank you soooooooooooo much! I have spent so many hours determined to get this working and have given up so many times. I can finally proceed to actually use this thing the way I wanted!
     
    You have no idea how happy I am right now...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines