• Content Count

  • Joined

  • Last visited

About Igor

  • Rank
    Embedded member

Profile Information

  • Gender
  • Location

Recent Profile Visitors

14136 profile views
  1. Not necessarily. Family can be divided only for legacy(rk3399,rk3399-1,rk3399-2) and merged on current/dev (rockchip64).
  2. - 5.6.1 has been branched - i am about to sort out 8189ES and FS to be ready and remove existing patches in this PR https://github.com/armbian/build/pull/1860 Legacy kernels only, right?
  3. AC speeds at 5Ghz, client number limitation unknown.
  4. https://www.google.com/search?q=How+to+remove+existing+docker+container
  5. Will be fixed. In my case, 21 devices, 2 passes = 357 minutes.
  6. The only sudo here is for installing dependencies. https://github.com/armbian/autotests/blob/master/go.sh#L13
  7. My auto test facility shows 1.8Ghz for Opi3 and One+, others are not hooked up due to lack of RJ45 so I don't know without looking to the code or test. IHMO for Nanopi Neo we should not change defaults. We have overlays. WG < 5.6 is maintained separately and also present in all versions of Armbian. But currently there are some problems. I believe DKMS should fix that and if not, this could be also a bug needs to be solved before 20.05. We fixed headers and sources. Changes to scripting comes with a board support package, ex. linux-root-buster-current-orangepi3.deb Do we know what will this merge drag with?
  8. Known problem, no solution yet, but its probably some init timings. Sometimes driver fails to properly initialise the driver. I do have this screen somewhere, but was never tested. Check device tree - perhaps/probably it only needs to be enabled. We ported this work: https://github.com/rafaello7/debian-installer-nanopi-m3 More or less it works what is written there and more.
  9. Consider that this method was tested by me when we added it, at 29.09.2018 and we didn't change anything.
  10. Yes, at 1 pm GMT which translates to 3 pm local time for most of EU based folks. I leave this open for each of you. Add, change, comment, be natural and reasonable - some tasks are good, some bad, some are pointless, some need more attention, some can't be done. Also important is to fill in and close (major only) tasks that has been done after release of 20.02. since otherwise it might slip out from the release documentation. Simply open a new Jira Task or bug, add a tittle and optionally a link to forum topic or Github commit / issue / MR tag with 20.05 and set it to "Done". I would propose to self assign, the rest we will do in the meeting by asking people out. Anyway we usually know who is working what, but keeping track at once place is generally good and also for those that are not here every day. Assigning is not obligatory to finish the task. If you can't, speak out, perhaps someone else can take over and / or simply change its status from "In-progress" back to "To-do". https://armbian.atlassian.net/browse/AR-71 Yes. The idea is to lower the load. I am sure sometimes we start to work on a task that is sadly too big for us and frustration kicks in. If nothing worse. This will also give us some overview what kind of help we actually need. https://github.com/armbian/documentation/commit/9ea6bcf7c77db18aeaebdfed10fce301388d1a88
  11. Perhaps we need one example how this is planned and others can follow this? I am not sure everyone noticed this and even I was confused how this should be done. @sfx2000 @gprovost I would like not to deal with more gadgets at this point. We added Jira several months ago and we haven't manage to use much of its powers. IRC is nothing fancy, but its good enough. We have a channel recorder, no need to deal with any subscriptions and/or legal stuff. It works. Consider that many folks are old school or geeky, where IRC is the thing and already a Skype represent a far end of comm tools Anyway, my concerns goes to the meeting content. To come up with an agenda that will help us bring up, put attention to common problems and to spark our comm channel regardless of technology behind this. For the future, if majority decide we need to upgrade to something from this century , I will follow.
  12. Below Linux kernel 5.5.y is a legacy out of the tree version, this: https://git.zx2c4.com/wireguard-linux-compat Starting from 5.6.y WG is a part of the mainline kernel. Reports those errors / problems directly to WG authors and when they fix this, apt update and upgrade will solve it ...
  13. I ran it now on Odroid N2 and it gets stuck at: I will ofc not proceed with debugging this 3rd party software, but it would be good to notify the author that there is something wrong ... Armbian config script only calls their installer after installing Docker first: https://github.com/armbian/config/blob/master/debian-software#L1780
  14. Our next release date is coming and perhaps its time to discuss what to push into 20.05, what not, resolve open questions and distract from most used keyword for past few weeks. @Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @count-doku @chwe @ning @lanefu @gprovost @aprayoga @5kft @JMCC @Werner @karabek @martinayotte @tkaiser @selfbg ... to name just a few which might find this move useful I am preparing a meeting on IRC in Saturday at 1 pm GMT - this is reasonable good timing for US / EU folks. The idea behind this meeting is that (ideally) everyone, who will be present, quickly present (in alphabetical nick order) what they are working (not working on anything is equally legit) on followed by a discussion. If a feature, project or a fix can be pushed into this release. Plus answer and decide on other open questions. You are welcome to expand this with a PR/change document directly. This way we could - on a long run - improve all project parameters. As my example - what I am currently working and IMHO could be implemented by 20.05: - setting up auto test facility, software and hardware which is a great support tool for making releases. It is already helping me finding bugs. - merging mainstream kernel config in the non-hardware areas could go into this release - firmware split up with @ning ... more Jira's during a week. Ideally it would be that prior to this meeting you write into Jira what you are working and join discussion about your task/project/idea with a link - who does not have access shall PM to @lanefu or @Igor - reviewing and prioritising goes faster and better with Jira. Welcome!