Claim a task, set DUE date and start doing it!

[Igor]

[Ended]

 

Be active, creative, helpful and you can get a powerful board in return. First give away batch is starting 11.6.2016

 

It's not often that you can work on a software project that actually brings joy and helps people. Armbian is one of those project. It is a system that helps one build a kernel or boot images for several ARM development boards. 

 

It's in common interest that we improve level of support and to relieve most active people. Our crew needs an upgrade:

• we need more coders, kernel hackers, UX designers to find and solve problems. If you are one of them, join our forum, join project at Github.
• we need properly built, packed and supported desktop with major functions: video acceleration/fbturbo, libump, mali, etc.
• we need to put together much better documentation. We need to fine tune MkDocs documentation tools

For those who are willing to claim a task or help others to understand "how do I do this in Armbian" we prepared a dozen of boards as a small reward. It's a Xunlong Orange PI+ 2E, which design was improved based on requests from our community. It's H3 based quad core with 2G RAM, 16G eMMC, Gigabit LAN, WIFI and 3x USB.

 

 

There might be just enough boards for everyone who are willing to do some public service work. Claim your projects at this topic and each weekend we will discuss and select up to 15 people who will get the board, starting with 11.6., ... until we run out of boards. One will be notified by email and expect an answer within 48 hours, if not, board goes to somebody else.

 

Boards were donated and will be sent directly from Xunlong Co., Shenzhen, China.

 

---

 

1st batch is going to: Kriston, lanefu, vlad59, martinayotte, jeanrhum, Gravelrash, xcasex, naibmra, Xer0, madilabs, wha, @lex, WereCatf

 

naibmra - Bulgaria - kernel testing, try hooking to kernelci.org, docs - mid July

wha - USA - 50unattended-upgrades, issue #337 - June

Kriston - USA - documentation rework - July, August

Xer0 - Germany - media build - July, August

lanefu - USA - issue tracking improvements between forum and github - 22 June, July

madilabs - Martinique - Packaging for desktop video acceleration - June

xcasex - Sweden - desktop packaging - July, August

jeanrhum - France - documentation and debian packaging - July

martinayotte - Canada - maintain/fix DTS entries for some devices such I2C/SPI/W1 - ASAP

vlad59 - France - Nanopi M1 testing and documentation

Gravelrash - UK - Prepare HOWTO's & package "armbian-gc2035-fswebcam package" - June

 

2nd batch is going to: dimag0g, R2D2_C3PO, miked, 0x0, sysitos, jmcneill 

 

dimag0g - France -  Packaging of OpenGL wrapper library - end of July

R2D2_C3PO - Germany - Improved SD-Card partitioning - end of August

miked - Canada - build system recension - end of August

0x0 - Russian Federation - Redesign site and documentation WIP + add some changes to graphics in distro. - end of July

sysitos - Germany - replace/rework ramlog for systemd - end of August

jmcneill - Canada - (Armbian is helping porting Freebsd) 

 

Users were notified and were requested to provide: project name, due date and their shipping address

Edited October 12, 2016 by Igor
documentation tools

[tkaiser]

What I would love to see is someone joining our development efforts to provide all the stuff outlined by @rellla in this installation log http://linux-sunxi.org/User:Rellla/Armbian to be integrated into our build system.

 

A dev joining in willing to dig a bit deeper into Debian packaging so that all the aforementioned stuff could be integrated as Armbian .debs into our repository so we could provide upgrades the usual way (apt-get update/upgrade) and also real upgrades from CLI/server OS images to desktop images would be possible (if one tries to upgrade a server image now then most probably all stuff needed to get HW acceleration for media playback will be missing afterwards).

 

As far as I understand everything needed for A10, A20 and H3 boards is already in place so the missing step is 'just' integrating all these packages into our build system so at least users of the most popular sunxi boards could benefit from.

 

And at least to me the Orange Pi Plus 2E we're talking here about to be able to give away for free to devs wanting to join in (a big thank you to Xunlong!) would be the perfect board for this purpose due to 2 GB DRAM, pretty fast 16 GB eMMC, superiour PCB heat dissipation allowing high clockspeeds without much or any throttling occuring, Gbit Ethernet and onboard WiFi being not that bad according to first testers. Or am I'm overseeing something?

[Kriston]

I'd like to claim the documentation task to update lib/tree/master/documentation.

I can also assist with build tools, in particular their documentation and QA testing because I know from experience that good documentation comes from testing.

I have two each of Orange Pi PC, Orange Pi One, Raspberry Pi 3, Raspberry Pi 2, several Raspberry Pi 1 boards, and a PINE64 (uses Allwinner and Mali chipsets).

[lanefu]

I'm totally interested in participating.   Is the issues list on github the source of truth for open tasks or are there other places?

 

PS it looks like the issues in github arent taking advantage of labels.  probably worth while

[Igor]

@tkaiser

That's a good starting point. True. Not many things needs to be built out of nothing, which is motivational and saves time.

 

@Kriston

You are welcome to rework manuals - I hope you are good with Github since markup language is limited, but good enough for our purpose. First problem is lack of structure than missing parts. User part is technically relatively simple while advanced manual - you will probably need to play a little with building to get familiar.

 

@lanefu

Issues are scattered around, but most of them are under lib -> issues We don't label or arrange them since it takes extra effort, but if you are willing to take issues on another level, we will save lot's of time on a long run. 

 

Both ideas are valuable and welcomed, just start 

 

If you need any extra tools or permissions, please send me a PM.

[vlad59]

First thanks for this project and thanks for doing this kind of thing to make it bigger !!

 

I can't do much (not enough time in a day) but I can try some stuff anyway :

 * I can test many things on my devices (3 banana pi, 2 nanopi M1,a bunch of Raspberry PI, and even some Pogoplug, Sheevaplug and Dockstar from way back)

 * I can help with documentation

 * I can help with FAQ / documentation translation (in French) if needed.

 * I've also checked and saw that the project didn't use Travis or another CI, compiling all possible kernels and all the boostrap is certainly not possible but there's maybe some gain in having some check with Travis.

 

My only computers at home are my SBC (the list is up there) and my work computer running Windows so I guess I can't build easily Armbian.

[martinayotte]

Maybe I could help here, if it is not tasks above my capacities.

I could help on the DTS for example if something is missing.

[jeanrhum]

I can also help. I can easily work on documentation (and translation also in french if needed).

 

I can investigate some packaging stuff even if I am not a expert on this topic.

 

I have an orange pi 2 mini, which I can easily use for testing. I have also a banana pro and a pine64+.

 

Finally, thank you wery much for your work, my bpro as a nas, works so well with armbian.

[wildcat_paris]

I won't claim anything

 

Documentation has to be written, so I have opened a thread to select a tool to help documentation writing.

 

http://forum.armbian.com/index.php/topic/1337-documentation-software-proposal-for-armbian-wiki/

 

Feel free.

[zador.blood.stained]

I don't think we need to maintain documentation for several languages at once, so let's better have single language, but good coverage and quality.

 

I'm totally interested in participating.   Is the issues list on github the source of truth for open tasks or are there other places?

Some suggestions are noted in the first message of this topic. Also some GitHub issues need testing and checking documentation (i.e. #337), some require having a specific device to test (i.e. #286), some require creating and testing a small kernel patch (#222 and #323), and some are obsolete and will be closed after checking.

 

 * I've also checked and saw that the project didn't use Travis or another CI, compiling all possible kernels and all the boostrap is certainly not possible but there's maybe some gain in having some check with Travis.

Was discussed already, feel free to add your suggestions.

 

Documentation has to be written, so I have opened a thread to select a tool to help documentation writing.

For now I would stay at using Markdown as markup language, stay at maintaining user-level documentation in current state and maybe migrating build script documentation to GitHub wiki attached to main repository (https://github.com/igorpecovnik/lib/)

[Gravelrash]

@all

 

can you elaborate on what you are seeking around the following "we need properly built, packed and supported desktop with major functions: video acceleration/fbturbo, libump, mali, etc."

 

i already build my own desktops using whats available on the base desktop environment you supply and changing packages to suit. its all standard repository stuff. Im happy to get involved where i can

[zador.blood.stained]

can you elaborate on what you are seeking around the following "we need properly built, packed and supported desktop with major functions: video acceleration/fbturbo, libump, mali, etc."

Packaging scripts to turn libraries (i.e. https://github.com/ssvb/xf86-video-fbturbo )into .deb files

First, check if each component can be cross-compiled, if this is not possible, compile it in chroot.

Second, pack all compiled stuff into proper packages - check this for an example. It still needs some cleanup, but this should give you an idea of packaging process - create directory structure, create control file and maintainer scripts (if they are needed), copy files to proper directories, pack and check results.

[Gravelrash]

i will give the above  a try before i commit to taking it on

[xcasex]

Like i mentioned to tkaiser on irc i'd be willing to take on packaging, seeing as how Gravelrash beat me to it I think we can tag-team it.

 

what i'll be looking into is reusable package templates, metapackages & taxonomy as per the list summarized by @rellla

 

ps. Gravelrash, hit me up in a dm if you're up for collaborating.

[Igor]

Most of tasks benefit from team work - you are welcome to join / claim already claimed tasks. If you need anything special, just ask.

[rellla]

xcasex: If you need help regarding package (not packaging ) details, feel free to ask. In the meantime, i'm preparing a rebased libvdpau-sunxi branch which should work with H3 and include things like CSC fixes aso...

Regards

rellla

[naibmra]

Hello,
I follow the linux-sunxi commynity for >2 years. Learn about this on the IRC channel (thanks to tkaiser).
(BTW why don't you post on the mailing list also?)
I want to volunteer myself. I can help with testing and reporting bugs, because I lack hardware expertise to write low level/kernel stuff.
Also will take the board to my local hackerspace and hook it up to "https://kernelci.org" - a nice improvement. There are a couple of C.H.I.Ps and a dozen Rasberries (have to check what else). I'm also waiting for the H3/A64 OSHW boards from Olimex to be released.
I have more time for running various tests and also would like to give a try to experimental stuff like THS, emac , DRM for the H3.
I'm more interested in mainline but can run the 3.4.x kernels for comparision when needed.
Other things that comes to my mind are writing newbie friendly guides/tutorials
and shift through the github issues to see if anything is my competency.

Kudos to you! (and thanks to Xunlong too).
Best Regards.

[Gravelrash]

im up for collaborating,

 

My experience of software compilation / packaging beyond --check-install is limited at best. hence my offer to try it before i commit.

 

PM sent

 

Like i mentioned to tkaiser on irc i'd be willing to take on packaging, seeing as how Gravelrash beat me to it I think we can tag-team it.

 

what i'll be looking into is reusable package templates, metapackages & taxonomy as per the list summarized by @rellla

 

ps. Gravelrash, hit me up in a dm if you're up for collaborating.

[xcasex]

Awesome!

I'm a bit boring since i come from a technical infrastructure architecture background so i prefer to do things like defining scope, goals etc. 

 

going forward i'll be replying in depth to your dm so we can hit the floor running, we should also do some outreach and see if its feasible to have a pie in the sky goalset as well. 

 

Cheers,

Robert.

 

im up for collaborating,

 

My experience of software compilation / packaging beyond --check-install is limited at best. hence my offer to try it before i commit.

 

PM sent

[xcasex]

oh you prescriptivist  

excellent, are you focusing on libvdpau solely or looking to branch out into the other items on the list?

 

 

xcasex: If you need help regarding package (not packaging ) details, feel free to ask. In the meantime, i'm preparing a rebased libvdpau-sunxi branch which should work with H3 and include things like CSC fixes aso...

Regards

rellla

[xcasex]

Thank you, i'm not much for out-competing anyone, collaboration is more my thing. but i'll be sure to ask if i hit any roadblocks

 

Most of tasks benefit from team work - you are welcome to join / claim already claimed tasks. If you need anything special, just ask.

[zador.blood.stained]

@xcasex, @Gravelrash, @rella

 

Some notes:

 

Currently we have these prebuilt desktop packages: https://github.com/igorpecovnik/lib/tree/master/bin/sunxi-debs

You can extract control files from these packages (using "dpkg-deb") to use as templates.

 

I believe MPV and *dbg* packages are not needed.

 

Target releases for desktop support are Jessie and Xenial, so don't worry about compatibility with Trusty and Whezy for now.

[xcasex]

Thanks for the heads up, are there other little bits hidden away that we might benefit knowing about?

 

 

@xcasex, @Gravelrash, @rella

 

Some notes:

 

Currently we have these prebuilt desktop packages: https://github.com/igorpecovnik/lib/tree/master/bin/sunxi-debs

You can extract control files from these packages (using "dpkg-deb") to use as templates.

 

I believe MPV and *dbg* packages are not needed.

 

Target releases for desktop support are Jessie and Xenial, so don't worry about compatibility with Trusty and Whezy for now.

[zador.blood.stained]

Thanks for the heads up, are there other little bits hidden away that we might benefit knowing about?

 

Don't know if you can call it "hidden", but you may want to read official Debian packaging documentation and tutorials (i.e. [1], [2], [3]) - this describes "proper" way - using debian/rules file instead of creating and populating directory structure manually (aka "quick&dirty" way of building packages).

 

Also you may check this (Note: fbturbo is beneficial for both legacy and mainline kernels!), this (pay attention to the warning about partially outdated instructions) and this. Also Rellla's wiki page about Armbian has tons of useful stuff.

[Xer0]

i've succesfully compiled media_build drivers on/for Orange Pi

could share how to circumvent the caveats if someone needs

[madilabs]

Hello,
I claim the tasks described by tkaiser.
I used to write bash script for build deb packages of kernel patched with grsec.
Now i don't use the kick way to build deb. I use & hack jenkins-debian-glue to create and manage deb repositories.
Today i will be glad to use and improve my skills for the dev team.
So for me, it's possible to use simple bash scripts or use jenkins-debian-glue to build native or cross-building deb packages.

•     Native and crossbuilding deb packages with basch script (easy)
•     Native deb packages with jenkins-debian-glue (easy)
•     Crossbuilding arm deb build with jenkins-debian-glue not featured (maybe done with hack)

I fork the project (https://github.com/madilabs/lib branch deb_packaging) and give a first try.
For the moment the first point is done, tested on a odroid-U3 and build deb from source (.dsc file)

After testing i will try the stuff outlined by @rellla

[Igor]

@Xer0

 

https://github.com/igorpecovnik/lib/blob/master/desktop.sh

 

We need implementation there, within build process. Current way is outdated, a bit dirty and need an upgrade. It looks like it's still working on H3 but failing on A20 since certain libs needs updated versions. We need a solution which is build from sources to get rid of outdated prepacked libs and pack output into .deb that we can provide an update. Only complete solution makes sense since we already have some temporally solution.

 

@madilabs

 

Check our way of packaging. It's fairly simple, no need for any extra tools.

https://github.com/igorpecovnik/lib/blob/master/extras/tools.sh#L33

 

Later tonight we will be selecting for the first batch - already moving tasks are having advantage.

 

add.

... and well designed and not yet working procedure is better than a quick fix.

[wha]

I haven't read through all of the issues, so haven't picked anything to do yet.  But I'm willing to help.

 

I've ran Debian since 'Ham' (early 2000's).  And have done embedded (8 & 16 bit) off & on for years.  Recently I've started to play with [8 bit] AVR & [32 bit] Arm (Teensy 3/LC).  Haven't done Linux drivers (never had a need to at work).

 

I've an Orange Pi Plus 2E, will probably get a Orange Pi PC, One, & Lite for misc home projects/experiments/learning.

 

Thanks,

    wha

[Gravelrash]

@all

 

I have had a go at what you suggested and i need to spend a LOT more time getting to grips with the fundamentals, so I wont be claiming any of the deb and packaging side.

 

I think that @Xer0 & @madilabs & @xcasex & @rella would be more suited to this task

 

I will resign myself to doing HOWTO's for armbian as and when i spot the need for one.

[tkaiser]

Since I'm currently trying to integrate @lex' latest patches to support the cheap GC2035 Orange Pi camera as driver into our sun8i legacy kernel another useful task would be to package @lex' adopted fswebcam version so we can deliver this armbian-gc2035-fswebcam package through Armbian repo.

 

Anyone?