-
Posts
13936 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Everything posted by Igor
-
This way: https://docs.armbian.com/Process_Contribute/
-
https://www.google.com/search?q=Can+you+pleas+tell+me+what+should+I+do+with+.zst+image&sourceid=chrome&ie=UTF-8
-
https://docs.armbian.com/User-Guide_FAQ/#why-does-hardware-feature-xy-work-in-old-kernel-but-not-in-more-recent-one Check the rest of the FAQ too.
-
Radxa Zero: What images I've tried so far and what has and hasn't worked
Igor replied to minnixtx's topic in Radxa Zero
@Yakovis listed as a maintainer and could know what is the status. I don't have the board nor time to deal with this hw in particular. Currently we are trying to find out status for upcoming 22.05 release. If that would not be possible, we will be forced to remove the support status and cut down investments, "competition" included. Usually if one doesn't boot, others will also not boot since its something wrong with a boot process. If hope those boots as expected: https://imola.armbian.com/dl/radxa-zero/rc/ Since they are abusing our resources they must have more time to test. Going that route seems to be the right way and we all will have much worse software support, but otherwise doing well. By getting a subscription you can help mitigating costs. Regardless which OS you will use, original or copy. -
Yes, it was tested, briefly, but since we don't have a dedicated maintainer or support sponsor, there is nothing we can do. Images will still get better and better since general support will be there and kernel support from Raspberry Pi foundation is also updated almost daily. But for those things in between additional man power is needed, which we can't find or hire (we already generate loss).
-
Rock Pi 4: Does ArmBian build their own U-Boot and TF-A binaries?
Igor replied to lag-linaro's topic in Rockchip
OP place this question on many forums and chat channels so I am sure he found it by now. AFAIK we also do but he can also look into the code like anyone else. -
The case is that with all those actions we are actually forcing you to start thinking about supporting us - currently you support our work with less then 0.5%. We can raise this number in two ways - cutting the value we are giving or you start giving something in return. If we fail to persuade you to help and invest into our work, we have nothing to loose. You loose. Our copy cats can only provide the same. Alternatives are here to deceive - add as low as possible or just something and take as much as possible. Remember that by using our kernel means they don't need to invest nothing into R&D, sales only. This is totally different league. We have to. Their support, when it comes to expensive to solve problems, looks like this: Their "customers" which costs them close to nothing, but costs us a lot, perhaps even donating them money because (our) OS works so good ... They steal from our work and also steer their customers to us to steal more, even we asked them not to, even they know we will not support them since we have no budget to support expensive technical problems even for people that believes in us and supports us. In case you don't want to have half working software that is destined to fall apart sooner or later with fake support or as cheap support as possible (Manjaro, Arch, Debian) you actually have no alternative.
-
Locales problem again - are you seeing this: http://ix.io/3Yhy Seems to be Debian bullseye thing, since Jammy doesn't have that.
-
That is possible, but features in mainline kernel are breaking down in regular cycles if not maintained. Most people wrongly assumes works is done when hardware reaches mainline, but that is not the case. When hardware, especially of cheap HW such as Rock64, gets here (never with all functions supported) it starts the journey of breaking its usable features down. We are seeing this everywhere and without our intervention many board would not be usable at all anymore. Those interventions could (are) easily costs somewhere between 5 and 15k euros per board per year. Current cost covering scheme - you as our "clients" are only adding 0.5% of needed. CSC -> Supported didn't fix you the problem. It only helps sharing the non most critical burden: Someone will keep a list of what is not working, but he/she is not obligated to do anything. We also accept people that has no clue about R&D. If this would be a requirement, most likely nobody would show up. But this is again just a wish / theory - in reality - very little of those that joined actually does anything on that list. They report nothing, they don't (all) participate in release process. When there is no help, status is going back again ... If someone pays hours needed to fix the feature / bug, someone will try to fix it. If not, bugs stays. This is not a problem of Armbian since public is not even trying to cover expenses related to keeping the device usable.
-
Let me explain how CI should build images. I am generating packages with a regular build train: https://github.com/armbian/build/actions/runs/2360625136 It generates all kernel packages, firmwares, desktops and all u-boot + board bsp. Then i put packages to the nightly build repository which currently contain (should contain) latest packages made from v22.05 branch and labelled this way too. Next I use a script "Build images" and choose extra parameters: - build RC images (stable is identical, just they are placed to /archive instead of /rc) - which runners will be used (not relevant build performance tweak) - which is the source branch (v22.05 in this case) Now there are all sorts of problems possible: - error reporting is not the best and we can easily have false positive build. Corruption can happen if some runners goes out of memory or space. Happens from time to time. - yesterday i have deleted repository by mistake and i need to recreate it (no technology in place at that storage) - i have many troubles with local lan due to failed attempt of refactoring - NAS often timeouts and build has to be re-done - Github is unstable when providing Docker images, when starting Runners, CI because of that is not 100% reliable - all this process is still half manual In short term, no. Long term - start learning Github actions. We need to cleanup the code and have more people that can jump up and fix troubles if they arise. Code complexity is going up and most of the code there is completely without any proper commenting or history. It was ad-hoc on ad-hoc on ad-hoc ... its time to get things in some order.
-
Rock Pi 4: Does ArmBian build their own U-Boot and TF-A binaries?
Igor replied to lag-linaro's topic in Rockchip
Thank you! I know it works best. We have sponsored this development for the ones that sold you hardware. You can make a donation here. Before you burst out with one million dollar questions that can only be answered to business clients, take a look at FAQ. BTW. This is open source, so we are not hiding anything. Just if you are not covering our time, we can't help. I hope you are able to understand that. -
When RC builds are out, we need to test them. CI ads some troubles and this way we can fix that too. I already find and fix many issues with CI. Practically lost a week just on stabilising that.
-
Since they have no R&D outside scripts that changes appearance and install some apps that would be some random act, probably something is not fully updated or they use stock FriendlyArm presentation kernel. Either way this is on you to find out if you are interested to know. We have enough of our troubles which is why we are limiting what we will do.
-
Their "support" means they download Armbian, unmodified and untested upstream kernel (Manjaro) or presentation kernel (from HW seller) and put on their label. In case you want to see a board supported, start to understand that supporting hardware generate expenses. We can't steal the value from Dietpi, Manjaro or others, since they are not creating it. Take your time and read those pages - its well explained: https://docs.armbian.com/User-Guide_FAQ/ https://docs.armbian.com/User-Guide_Board-Support-Rules/ (as you can see - images can be back if someone take responsibility under certain conditions, some burden away) https://www.armbian.com/newsflash/armbian-needs-your-help/ tl;dr; Sadly also when people said they will help, they don't show up when little help is needed and there are so little donations and subscriptions that they have absolutely no impact on the costs. If costs are not covered not even in 1% how do you think we can help you?
-
Protocol says that bug has to be recognised by board maintainer - if he spots this and he see this as a problem. Then if he chooses to help you instead of playing with his kids, he will put the bug into the system. This again means nothing since average bug closing time (for bugs the gets into our system) is around one year. I sense you are only willing to wait few days top and you are certainly not ready to pay for the service. Am I correct? Werner helped you to understand what are minimum standards when sharing a problem with community. He is also helping newcomers that they don't get lost or that you don't do some stupid things in this world. He is not a developer and will not deal with your problem in any way. By providing basic data you raise chances that random person, the one you are referring as "members helping each other" will help you solve this problem. He helped you to raise chances to something that is not almost exact 0%. Remember - there are 1000x more bugs than resources dealing with them.
-
Better, yes. I was looking if this would be possible to split up, but its simply way too much work.
-
@Contributor/Maintainer "missed released will result in immediate forfeit of “Armbian Supported” status and demotion to CSC status unless Armbian team grants exemption https://docs.armbian.com/User-Guide_Board-Support-Rules/ Probably board maintainers are not aware, status will be dropped to CSC in case they don't show up. @yang Can you send them a notice to help with testing? One RC images are out and new RC will go out probably this weekend.
-
Found it, will make a PR at once. Edit: yes, seems ok.
-
Means nothing. https://docs.armbian.com/User-Guide_FAQ/#why-does-hardware-feature-xy-work-in-old-kernel-but-not-in-more-recent-one Anyone can adopt it for you. Armbian is free software and provides best effort help through community forums. If you can't find answer there and/or with help of general project search engine and documentation, consider hiring an expert. We are already blowing too much for public good and there is nothing coming back: https://docs.armbian.com/User-Guide_FAQ/#why-is-armbian-constantly-asking-for-money-free-software-should-be-free When / if solution is found, this way its implemented with lowest additional damages https://docs.armbian.com/Process_Contribute/ Of course project problems doesn't stop here. Review process is needed and long term code maintainace also contributes to the costs. Again FAQ: https://docs.armbian.com/User-Guide_FAQ/#support-time
-
They were build from here https://github.com/armbian/build/tree/v22.05
-
@Contributor/Maintainer RC images are present (a few are still missing) https://imola.armbian.com/dl/ (not so fast download, so please be patient) Known problem: they all reports as nightly builds
-
In order to have random hardware supported, you will need to invest quite a lot ... its not simple and its not one time job. And certainly not for one person. To not go too deep over and over again, check: https://docs.armbian.com/User-Guide_FAQ/ We probably can help you, but you will need to cover our bills. As a professional service. If this is not the case, dig into the code, read documentation, search forums ... don't be a burden to maintainers. They don't need more work on their expense. Instructions are again something we can't provide for free, hints are: https://github.com/armbian/build/commit/f60920a2b776b544c9e37cddec8d495d22e2867c https://github.com/armbian/build/commit/2a8e1ecac1c4fdbf986034be9d6c05a8f1b6e6fb https://github.com/armbian/build/commit/3da96b2d779d45dad634e0b5868ed2cac533e70a I am afraid this level is not an Armbian level problem anyway. This is chip / vendor problem and expense and we have no interest to deal with more hardware. What you want to achieve is complicated also for people with hardcore engineering skills and years to decades of experiences. If you want to participate and be useful to the project, check roles that fit your skills or where you want to invest time to learn.
-
They are providing old working kernel even you only paid hardware at BOM price. Not saying everything works, but for the price you pay (nothing) ... its something to boot. If you want luxury you mention before, you need to actively contribute. What is wrong with not getting an answer?
-
Since he didn't asked if we have any costs with that, we should rather close this idea right now?
-
Currently spotted bugs: https://armbian.atlassian.net/browse/AR-1194 (research) https://armbian.atlassian.net/browse/AR-1193 (pr + testing) We need to check if build targets (focal, jammy, bullseye, desktops this or that, ...) are suitable Will provide RC today. Some images are missing ...