Igor
-
Posts
14365 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Everything posted by Igor
-
Armbian related videos / video documentation thread!
Igor replied to TheLinuxBug's topic in Announcements
-
Rock Pi S Jammy image fails, Bullseye image works
Igor replied to Matthijs Kooijman's topic in Radxa Rock Pi S
Indeed. I would bet we have some undetected error in CI build process ... We are putting hopes to bring up armbian-next up as soon as possible as this will also give improved error detection and logging. In case you manage, welcome. Thank you for your input. -
https://github.com/armbian/build/blob/master/CONTRIBUTING.md#generate-new-patch-template
-
6.1 is currently available only in beta / nightly repo. Switch there first, then you will be able to chose 6.1.y.
-
Event -> Video (with transcripts and comments) 1. Merging NEXT (Jira tickets / updated slides) We discussed progress and problems. Help is needed with: enabling CI developer perspective testing -> test all boot loader, old boot loaders, especially armhf images: cubox-i, odroids, clearfog, ... user perspective testing desktop (currently is broken?) 2. Encourage end-users to open bugs to Jira? Replacing https://www.armbian.com/bugs/ with instructions how to add a bug to Jira seems like a good idea. But this will be community managed without any obligation from Armbian team. Basically introducing a proper bug tracker. Existing AR-XXXX issues that are hardware specific should be moved there. If we have a consensus on that, we have to make a plan, write proper instructions and launch it ... or forget about. 3. Move developers forums to GitHub We were weighting idea to try to encourage more discussion on GitHub and have forum more users oriented. For start, we can try to enable Action - if label discussion is raised, it automatically creates a topic on GitHub discussions. Or similar. If we do that, we should first deal with hardware related bugs. For 2 and 3 we didn't come to any common conclusions except that communication is fragmented around forum, git, irc / discord, emails, PMs ... Comments on all topics are welcome! @Contributor/Maintainer
-
I am open for this idea - one of you needs to take responsibility to make it happen - I'll just run the build once is in the system. Can be discussed on regular developers meetings.
-
untilThis week meeting topics: 1. Checking the progress of Armbian-next 2. Providing stable builds for main TV box image? 3. General goal of weekly meetings: To discuss the three (3) issues of the week Discussions will be documented to respective Jira tickets so they can be tracked Three (3) new issues will be selected from Jira for the next meeting The purpose of a weekly developers meeting is to coordinate development of the build engine, continuous integration, operating system features and low level support. Meetings are hosted located on Zoom (Video) and IRC and Discord (Text). While we would prefer you attend on Zoom when possibly, we will also monitor text chat during the call for those unable to join Zoom. Please RSVP either way. Do you want to participate or help in some way? Meetings are focused in developers top level topics and its expected that understand embedded software development, software testings or operating system management. In term of programming languages, knowledge of at least BASH & Python is expected. Since meetings are held in public, any registered community member can join and listen. If you want to suggest issues for the next week, you have to be recognized Armbian contributor. If you want to become one, resolve at least one intermediate level issue and tell us something about you. This is needed to efficiently communicate and to give you access to our organisation infrastructure Jira, Github, hardware lab and servers. @Contributor/Maintainer @MattWestB @jock @SteeMan
-
This was most likely solved by now, but don't have a device to test. @monkaBlyat @Yakov
-
Armbian 22.11 Bullseye / Jammy Kernel 4.9.318 or 6.1.4 Release date: Jan 10, 2023 Legacy kernel has more or less full hardware support, while mainline lack functions such is wireless, HDMI, ... https://www.armbian.com/orange-pi-zero-2/ Looking for maintainer!
-
I forgot sorry. Then Git. For kernel sources it makes - as we make changes to it. Main distributions changes kernel a lot less then we do and they all provide source packages of that modified kernel. If we are talking about https://github.com/armbian/build/tree/master/packages/extras-buildpkgs then this is optional. I don't think anyone would seek source package for those few things we are building there.
-
I also see this concern. Proceeding too strict could backfire in this regard. Build framework (master) is already too advanced for average Joe. Default build process has to remain looking simple. Also regarding patches - we have to expect users will throw in all sorts of garbage patches (exclude sanity check from /userpatches perhaps?) and we have to accept even not formed completely in order. Only we and pro users needs that we are reminded patches are not formed well, others not. Something that should be behind "EXPERT=yes"?
-
Banana Pi M5: The last images don't boot anymore from SD card
Igor replied to atone's topic in Banana Pi M5
Some people had troubles, indeed. Images were replaced today and they have been tested. Try. (download might be slow / not synced to all servers yet / use torrent or retry if you are going to try within next couple of hours) -
We have to leave personal preferences and grunches behind. The tool should be developed into the direction that this doesn't represent a problem. Since this tool was developed "as it goes", naturally, it has many design flaws. Which resulted in strange decisions. Lets remember that compromises were made out of necessity, lack of time, ... We have to be constructive, improve communication, planning & coordination, ... @balbes150 If a major redesign is needed on top of NEXT, we might need to deal with it later as otherwise we can't bring this in. If a design problem is recognised, open a Jira ticket and describe why you think this or that implementation is bad. If its a small change and if we are united, we will rework it at once, otherwise this will be put into back log. Someone has a better idea?
-
I agree. I am trying to enforce needed coordination and structure by at least organising meetings, shuffling Jira tickets (this should be done by more people) provide tooling and am available for anyone from the team at any moment. At the same time I am trying to recognise / define our limits and scale it into the frame that is controllable. As too small resources provoke stress. Oleg builds his things on arm64, but we have to cover more, perhaps some stupid things for legacy reasons. We can't cut off blindly. I am totally aware that we are dragging 3/4 of those without any point, but someone has to remove them and be sure nothing is broken ... but since this falls off with the NEXT, why wasting time dealing with that? Lets focus into seeking for solutions. And compromises. I am sure we will need to make some - our common goal is have the tool maintainable and modernised. And this is not a fixed thing - when better ways are found and if most of us agree that something can be removed, we remove. If not, its better to stay. There are people out there, that are using this build framework. We don't want to cause stress to them.
-
Thank you! Impossible without help of: @Contributor/Maintainer @Moderators https://github.com/orgs/armbian/people https://github.com/armbian/build/graphs/contributors https://docs.armbian.com/Release_Board-Maintainers/ ...
-
Aha you mean like having a proper "software design" phase ... Currently we have "I have an idea and will work on" and we want to have some process: idea -> discussion / developers meetings / comment on that / co-design -> Jira story (or a plain document). And repeating those cycles until we are happy. Then coding. Yes, that would be ideal. The problem is that all this planning require a lot of resources we don't have. Ideally we would have a dedicated manager of software development. I am now doing this, running a business, doing paperwork. I am forced to improvise, make things on a "best effort" way. I hope that we will implement design mechanism into developers meeting and after. But at this stage we have a large branch of a build system that was not designed together, but is based on common design.
-
1. Feature implementation is different and you don't like it - propose changes (if its questionable, we vote), task if small, story if big 2. Something doesn't work - bug ticket 3. Feature is missing - describe what you are missing (task if small, story if big) You mean this?
-
Yes of course. I can say that current focus is optimisation for running as stable as possible and running within CI. We need to have this phase in near to perfect state before heading to optimising it for low resource systems. There are bugs that needs to be discovered and fixed before we proceed. I would suggest that for those ideas simply simply open a ticket. Our build system contains configurations, build lists, helper tools, speak multi arch, speak multi branches, supports different underlying packages assemblies, can be assembled on different arch, have many levels of caching ... acts like a giant compiler and linker. Perhaps a bit philosophical
-
Agree, I already opened a ticket: https://armbian.atlassian.net/browse/AR-1454 Current state of logging is terrible on the other end while if something breaks, logs can help to diagnose - the more the better. Perhaps we could introduce better levels of logging? Dunno how hard this is from current perspective? Cross compilation is one of the core tool advantages - removing would be a mistake. The rest I can't comment as I didn't study enough yet.
-
Looking for a volunteer to split kernel-drivers.sh into functions, for aufs/wireguard/kali/exfat https://armbian.atlassian.net/browse/AR-1478 If this is not ported, we will probably just drop it. But on the other hand, this is easy task and nice opportunity to understand armbian-next better and help.
-
Fix for packaging mechanism https://github.com/armbian/build/tree/master/packages/armbian won't be accepted as the problem is not there. This has to be solved with a kernel patch. Since this is a private kernel, it doesn't get most of common fixes. I remember lds problem was present some time ago in all kernels, but solution is long gone from my head.
-
untilThis week meeting topics: 1. Checking the progress of Armbian-next 2. Encourage end-users to open bugs to Jira? 3. Move developers forums to GitHub? General goal of weekly meetings: To discuss the three (3) issues of the week Discussions will be documented to respective Jira tickets so they can be tracked Three (3) new issues will be selected from Jira for the next meeting The purpose of a weekly developers meeting is to coordinate development of the build engine, continuous integration, operating system features and low level support. Meetings are hosted located on Zoom (Video) and IRC and Discord (Text). While we would prefer you attend on Zoom when possibly, we will also monitor text chat during the call for those unable to join Zoom. Please RSVP either way. Do you want to participate or help in some way? Meetings are focused in developers top level topics and its expected that understand embedded software development, software testings or operating system management. In term of programming languages, knowledge of at least BASH & Python is expected. Since meetings are held in public, any registered community member can join and listen. If you want to suggest issues for the next week, you have to be recognized Armbian contributor. If you want to become one, resolve at least one intermediate level issue and tell us something about you. This is needed to efficiently communicate and to give you access to our organisation infrastructure Jira, Github, hardware lab and servers. @Contributor/Maintainer
-
-
Profit is that sweet deal when you cover costs. Community / amateurs rarely work on boring cases that last weeks or months to finish in exchange for absolutely nothing, not even satisfaction of helping people as nobody will notice or understand their sacrifice. You can bump into the people, this community is full of them, that will help you with extremely valuable advise or hint - most things are solved for free. By us, by community. But you also want that hard things are solved for free and here things stops, sometimes brutally. In most cases they don't progress as they are costly in technical and organisational sense. If you treat this project with 20 or 200 USD per week, while we need 5000 USD per day to match costs, we are very very far apart. Most used business model to profit in OSS is to steal from someone and sign below. Nobody will sue you as its too complicated and how a non-profit can allocate money for that? Certain % of people will fill sick, some will complain and point towards dirty players, while you / end users just want to have free fun. This seems to be pretty typical profile around here I could point myself close to that, except that I am using my experiences and skills to progress this project. Alongside with others.
-
You should create one in the 1st boot process. Otherwise: https://www.google.com/search?q=how+to+create+user+on+debian+system
until