Igor
-
Posts
14558 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by Igor
-
-
Until two weeks ago, we also didn't have bootlogo on Pinebook. You probably need one of the patch from here:
https://github.com/armbian/build/tree/master/patch/u-boot/u-boot-pine64-default
This update is not yet present in repository.
-
Installing KODI is not trivial on any general OS / Debian / Ubuntu, not even on x86 machine. Second, you try to install it on modern 4.x kernel, which arrived on XU4 months ago and it's not matured. I have no idea if this is already possible. Third. Armbian is not focused to provide multimedia / closed source drivers by default, while I think it should be possible to build KODI on top of Armbian. In any case, start rather with old legacy kernel, check (at hardkernel forum) which additional libraries are needed and than you have much better chances to succeed,
-
When "include beta and deprecated images" is checked, Why is my board not supported? link pop's out and that will be relinked to github or rendered here: https://www.armbian.com/unsupported/
That's really all for today. Have to do some barbecue
-
Bump. It's done in one page and communicated clearly.
-
22 hours ago, tkaiser said:
Since while supporting such devices might be absolutely wrong but board bring up could be fun we could treat these devices simply as 'WiP forever'.
What about having yet another section with "Limited support". This means they are still getting updates, but no end user support exists for those?
"No support" section will need some extra work for now and for the future - if we want to have it solved in same design as those boards. If only a link to some .md or forum post, than this is no problem. -
I push some update on text & colours.
-
What about this way? + some small print at each section? Dividing into more pages doesn't seem to be this century web design technology
https://www.armbian.com/download/
Which boards should also go to WIP section?
The rest I'll check in next days. -
4 hours ago, t-bob said:
Where do i log the other issues ?
Kernel features -> Github https://github.com/armbian/build/issues and we will slowly put them in. Always provide for which kernel you those features go. -
I attached temp meter to heat sink and can't get higher readings than 49°C, Clearfog is not in a box and ambient temp is around 22°C. Adjusted:
https://github.com/armbian/build/commit/e5579a0957fd7b394d3b418671b4f0f82b334be9
-
12 hours ago, Tido said:
Will you open a section in the forum '.unsupported' - so there is a place where those Threads can be put as well ?
What about just removing unsupported board(s) from forum description & closing new topics with "no more active support"? I don't expect much if any activity on those boards.If no objections pops out, those four will get last update with 5.30 and will be moved our from armbian mainline support.
-
IIRC it's a leftover from first kernel, which had wrong readings. I'll check and adjust values ...
-
On 28. 5. 2017 at 8:52 PM, zador.blood.stained said:
Prepare a list of boards that should be phased out and reasons for that (no HW samples, no vendor (BSP) development, no mainline development, no documentation, HW design flaws)
My proposal for removal:
https://www.armbian.com/orange-pi-mini/ (limited edition, no samples, never sold)https://www.armbian.com/orange-pi/ (limited edition, no samples, never sold)
https://www.armbian.com/lemaker-guitar/ (no development for some time, design flaws, no mainline)
https://www.armbian.com/roseapple-pi/ (no development for some time, design flaws, no mainline, never sold)
-
4 hours ago, Richard Fortuna said:
Word to the wise: Firefox maxes out the RAM and WILL freeze your Pi. Midori runs GREAT though!
Firefox arm64 is known to crash, so we used to add arm32 version which works, but the fastest is supplied Chromium. Midori is also good choice since its light. -
-
Rules or protocols saves time and helps us to cope with problems regardless if this project is powered by this or that motivation. Well, we can't hire people, since our budget is on "let's go for a beer level", but we have to be more creative. We can talk about and I am sure, we have enough smart people around to come up and go with the plan.
- nightly images. If they are moved "somewhere back", we solved the other half of the problem. We already added lot's of warnings and we can add them more to the download page. Do we really need nightly images? If not, let's cut them down to minimum and focus to beta images, images build a week before major release? This way the testing protocol get's somehow simplified - there will be no question "where is the image which i need to test" -> "test last image from download", little less confusions, than using nightly images.
- support. If we already dropped the idea of commercial support, we could at least limit it to validated users / images and provide commercial support - as option. Since this is not mandatory it's more like a yet another donate button, but can help funding the project. Some cash will always be needed. This way we also cut off supporting 3rd party builders, which they have to take care of support on their own.
- config files and download page for unsupported / old creations. There were few ideas exposed, but I have some doubts on implementation. Build script .unsupported is good, but for download page I am not sure. Two examples - I would like to add new board to download page, we want users to try out and to see that we started to work on, but we don't provide end user support and on the other end we have some exotic board, which we want to move out from download page. We have one on without support and one off without support. This way?
Quotedoing only stupid support jobs in the forum, no more fun developing stuff
We need to limit support. Agree, but how not to make damage?My personal involvements are going above fun stuff sometimes - bigger the project, more comm and more coordinating. This can be fun, but it's usually dealing with people, where no schematics is available
Just saying.
QuoteThere's no one except Igor who could define rules
I can take veto, where and if needed, but I would prefer not to play part in every decision process, which is/will be going on. If core decision / active group expands more, than we might need to think about changing rules again. So far - in a small group - exposing a problem, talking about and making consensus is the way to go. IMHO Areas, where we all know what to do, we anyway do and no talk is needed. Here, probably we don't have unified standpoints and we shall clear them out, before any action is taken and resources wasted. Yes.
Quotebut as resources are not endless and one huge problem of every OSS-Project is to attract new developer and so MythBuntu died
I understand your concern, but usually there are many reasons involved. In any case, we are developing and attracting people, but the speed of overall development and users is faster / bigger.
-
In bridge mode you need a dhcp running on network. That's all. I also solve problems in NAT mode so both are (will be) working.
Wrote on mobile -
No NEXT (which can be identified / understand as stable kernel 4.x branch) for H3, while this situation already happened for older chips: A10 / A20 and Odroid XU4, Imx6.
Nightly images are not directly related. There will always be some development branches ... DEV will remain.
-
- default means old legacy kernel. Pretty much works, but ofc no docker support since kernel is too old.
- nightly indicates automated builds with whatever kernel
- we usually don't provide "DEV" images. Usually they are in nightly builds or you can made them manually
- in build higher than 5.27 (current betas) is it possible to switch kernels from armbian-config menu. So you don't need to worry about ...
- default will stay default for ever or at least for some time. DEV will become NEXT which indicates "Next kernel generation"
-
Check this image: https://dl.armbian.com/orangepipcplus/archive/Armbian_5.27_Orangepipcplus_Ubuntu_xenial_default_3.4.113.7z (desktop version is there too)
You can use armbian-config to create AP. I made a test - it works in bridge mode while it fails in NAT - I am still looking what is it.
-
2 minutes ago, jethro said:
What would be the recommended way of getting a Docker compatible kernel? I.e. safest path for most vanilla, repeatable, process, facilitating future upgrade?
You are using the most compatible kernel. This "DEV" will once become "NEXT" and that will indicate that we are satisfied with quality. That kernel updates will be from stable branches, currently they are not. -
8 hours ago, t-bob said:
Igor, yes i understand that they are very beta but I wasnt sure if it was a me issue or one that effected everyone. So far I have experienced only small issues which is really nice. armbian is pretty dang good !!!
I have found several other issues/'features' ... do i post them here or is there somewhere else to log them ?
I wouldnt mind having having the hamradio stuff setup in the kernel as a default ... with whom do i speak with about that ?
Thank you
I used to operate in hamradio field back in the old days, but I have no idea about current needs in kernel. If you provide a list of options (open a new issue at Github), we can include them in no time. Like this one. The same goes for other options you might miss in the kernel. -
46 minutes ago, jernej said:
I think that H3 will get DRM HDMI/TVE driver in 4.13 and Icenowy already tested mali driver (x11 version), which works. So it is not so distant future, but it will take some months for sure.
That's good news. I heard stories, but didn't know, that we are that close. Thanks for update.
-
3 hours ago, Richard Fortuna said:
No dice. Tried a fresh flash of the OS and xfce. Same thing. Very frustrating!
I made you a desktop build - it works for me, wireless works, the rest I haven't test: -
Quote
how long has the dev branch supported docker (i.e. 2 weeks or 6 months)?
We start to implement Docker in late 2015. I would not worry about that, but dev branch has still some low level glitches.4 hours ago, jethro said:- any known issues with the dev branch beyond 3d rendering / audio (my application is headless so that's ok)
There will be no 3D rendering in mainline kernel for next few years / never, perhaps someday in 3rd party branch. Audio works.4 hours ago, jethro said:any idea when a stable mainline build will be available for the OPIPlus 2E?
It's stable enough, but I won't use it in production at this stage yet. Or at least do severe testing on your app, before deployment. Few months. But not withing main line exactly (www.kernel.org), since support there is still minimal, development branches within Armbian.
Orange PI Win+ - apt upgrade issue
in Allwinner sunxi
Posted
Nightly / WIP / preview / development firmware (must) have bugs, otherwise we would call it "stable"
We provide those builds with purpose of bug hunting and since people expect that they should work (before job is done), we will stop providing them. We waste a lot of time explaining, that it's normal that things breaks, than fixing an actual problem. I made quick check, but can't find where is the problem.
Last time I was testing this feature, it worked as expected - from armbian-config, which does this: https://github.com/armbian/config/blob/dev/debian-config#L601-L615 when issuing "freeze kernel".