Plan for continuing with this project
MichaIng opened this issue · comments
@cclauss @Mictronics @jmichault and everyone else, let's make a plan how to continue with this project, now moved to the new @motioneye-project GitHub organisation.
First of all, everyone who has contributed to motionEye before, or wants to do so, please feel free to join in, also I think we can add everyone who is interested to the organisation.
I think we agree that Python 3 support is the first thing to achieve, given that Python 2 has reached EOL since over 2 years already, @jmichault and @Mictronics have Python 3 compatible forks from where we can commit back, and on this repo we have the python3 branch and a bunch of open pull requests for further related fixes.
I personally would go this way:
- Merge the
python3branch: #1572 - Rebase and merge Python 3 related pull requests
- Rebase and merge https://github.com/Mictronics/motioneye
- Rebase and merge https://github.com/motioneye-project/motioneye.eo
- A you did already start, so it's now python3-intl branch 🙂.
Approximately from simple to difficult, regarding possible conflicts 😉.
I would like to continue contributing in my way (docs and support, rather than code) if you'd like, as a collaborator.
I just invited you to the organisation. This way you should be able to create branches right here on the main repo, but I think this was already the case before, since you were a collaborator already.
I don't know anything about programming, especially in the github environment, I was able to edit the wiki documents, and assist end users as needed, and marking issues with the various flags (which hadn't been done prior to my being given collaborator status. I am a script-kiddie in python2 & 3, pretty good with bash and dos command (win) scripting, and so forth. jasaw (video/motion issues) and jawsper (brought an image of motionEyeOS) are both very good in what they do. I am a professional beta tester, too, since back in the Zoom Modem voicemail days (for the C64 & Early PCs), I can break things quite easily. I am an Enterprise (Level 2 & 3) Senior Help Desk, for the past 25+ years. I do translations between end users and developers. I have a lot of resources available for testing (VBox VM Server Ryzen7 CPU 32GB RAM/10TB Storage, Gbit network, Pi1, 2, 3B, 3B+, 4B-4GB and 4B-8GB, PiZeroW, 8 Network IP cams, 2 USB Cams, 1 CSI PiCam) and used them regularly for helping out here. I do docker some, too. If you go through the WiKi, I've done a lot of updates to a lot of the pages. If someone uses an esoteric (read: non-Debian based) OS, I'm willing to try to get it to work, and then document it...
Let me know if you can continue to use my 'services'....
One other question: Will this be applied to motionEyeOS too, or no?
That is very valuable, always good to have someone with some focus on the docs, issues/bug report review and testing side. Also Docker experience is good, which I lack, while I see the Dockerfile here.
I haven't had a look into motionEyeOS yet. I personally would concentrate on getting motionEye itself up and ready for Python 3 first, and then update Docker images and motionEyeOS in a second step. But those two definitely need others with more insights and experience with Docker and BuildRoot.
I would like to contribute, too, if my spare time allows me to do that. I am a long time developer and familiar with Python 3, Docker, Kubernetes.
My preference would be to add #2308 as step 0. given that it is now green and puts in place some important guardrails.
@cclauss
Okay, it doesn't hurt anyway. I made some comments as minor enhancements, otherwise good to be merged from my end.
I just invited you both as members to the orga. I'll send out invitations to all motionEye collaborators, which have their permissions preserved anyway. That way we also see who of those is still active and interested to continue contributing to the project 🙂.
Hello,
my python3-intl branch is ready to be merged : #2313
Awesome, many thanks for your work. From my end, I'd merge python3 first into dev and then rebase and merge PRs with python3 as base onto dev. It practically may not make any difference, after I resolved conflicts between those branches with the result that python is now up-to-date with dev, but it somehow feels more natural to me 😅.
@kleini,
Hello, I tried to modify Dockerfile to take into account all the changes made for python3 and internationalization.
Can you take a look to see what's left to do?
From what I see it contains all changes which were applied to dev/python3 branches before, so should be fine. Only thing which went inside as well is that python3-pip is not purged for the final image, while python-pip was purged before. If I'm not mistaken, motionEye does not require pip, so to reduce the container size a bit, this could be re-added to the list of purged packages. But as always, also since you switched (reasonably!) to Bullseye, it simply needs to be tested 🙂.
Just had a quick look on the "Install in Docker" wiki page and the Dockerfile. Building the container image works and the container works. Getting a picture from my network cameras works as well. So for a first step everything is fine. General questions from my side would be:
- Where is CI gone? I would like to build container images in CI and publish to docker hub or into one of the other container image registries.
- Today I would not build applications inside containers any more. I would build the outside and copy over the build artifacts into the container to reduce container size. But looking at the Dockerfile, a small container size was not a primary target before. Instead the container image should be able to do anything.
- Initial configuration file /etc/motioneye/motion.conf does not work.
- Help for configuration options does not work.
- Is there some Python 3 base container in some registry? Would that be the better base for a container image?
- How does motionEye "talk" to motion? I think, it would be usefull to separate motionEye und motion into separate containers if communication is possible across container boundaries.
- Move away from Docker and use buildah, podman, cri-o, containerd to get rid of no real open source dependencies.
Initial configuration file /etc/motioneye/motion.conf does not work.
Because motion is controlled by motionEye, and the motion.conf settings needed are in /etc/motioneye/motioneye.conf
I think, it would be usefull to separate motionEye und motion into separate containers if communication is possible across container boundaries.
Why? Why increase the complexity? Multiple points of failure? Diagnostics issues when something does break? Different versions / builds / new dependencies when something is updated? Have one force update the other? When motion updates and breaks the 'current' version of motionEye (it has happened) how do you control either?
With fixed versions in a single container, you update as a package.
The Docker IMO brings everything into the package needed to run to assist with the above questions.
From what I see it contains all changes which were applied to dev/python3 branches before, so should be fine. Only thing which went inside as well is that
python3-pipis not purged for the final image, whilepython-pipwas purged before. If I'm not mistaken, motionEye does not requirepip, so to reduce the container size a bit, this could be re-added to the list of purged packages. But as always, also since you switched (reasonably!) to Bullseye, it simply needs to be tested 🙂.
pip is purged (and the ability to exec in the container) to prevent people from making changes (similar to the RO file systems in motionEyeOS), from what I've discovered. Pretty effective. motionEye doesn't need pip after installed. Pip is only needed after install in a 'normal' install to do an upgrade:
pip install motioneye --upgrade
I think, it would be usefull to separate motionEye und motion into separate containers if communication is possible across container boundaries.
Why? Why increase the complexity? Multiple points of failure? Diagnostics issues when something does break? Different versions / builds / new dependencies when something is updated? Have one force update the other? When motion updates and breaks the 'current' version of motionEye (it has happened) how do you control either? With fixed versions in a single container, you update as a package. The Docker IMO brings everything into the package needed to run to assist with the above questions.
Because this large container needs to be rebuild completely for every little change. Maintaining a deployment is much easier, if different tools - motionEye and motion in this case - are in separate containers. The correct combination of containers can be controlled with various tools like docker-compose, kubernetes, Helm charts.
And furthermore motion requires a lot of CPU resources. Having those split across multiple containers improves overall performance. An ideal case would be to have every process running in its own container.
A container based on some normal OS like Debian Buster in this case, is often a problem with containers. Containers should not run an OS, making those containers error prone and vulnerable. As previously stated, a container just runs a single process. Having tools separated in this way, allows to have a motionEye container image, which only contains some Python runtime and motionEye, nothing else. If motionEye has any vulnerabilities the underlying container allows nearly no operations except running motionEye.
An incompatibility problem between motionEye and motion is a problem of pinning versions of both tools. This is not solved by a single container image. This must be solved by pinning these versions and it does not matter, whether they are in the same container image or in separated ones. And the motionproject already does provide a container image, so we don't need to download some built motion any more and include that in our container image.
Are you going to support cross host setups too, when people using clusters install motion on one host, and motionEye on another host?
Are you going to support cross host setups too, when people using clusters install motion on one host, and motionEye on another host?
This would be an interesting approach.
Because this large container needs to be rebuilt completely for every little change.
This is not really true. There is tons of documentation about the order of commands in a Dockerfile to reduce long builds.
The advantage, IMO, of a complete container, is you don't care what the docker host is running. The same docker for motionEye runs on all the debians, the RHs, the Arch, whatever. (Theoretically, Windows, too) without consideration of what is needed vs what is already installed on the host, and no communications issues between the packages (if the sandbox system WORKED, they would not be able to easily talk to each other, or possibly other containers...)
Because this large container needs to be rebuilt completely for every little change.
This is not really true. There is tons of documentation about the order of commands in a Dockerfile to reduce long builds.
If you read the option 3 in Install In Docker it pulls existing base 'images' of the OS, installs only what motionEye needs, and doesn't need 'get a cup of coffee' break. This was modified because of the age of software included in the existing version, and documented in the spirit of open source / open documentation on how to 'make your own mods'. If it goes the way of 'single process per container, and the complexities of managing many (possibly many, many?) packages and containers, I may fork the project (I will for me) because I deal with average newby non-programmers and developers who want to learn how to make changes or fit their situation without the need to go through a 4 year IS college degree to understand it.
IMO motionEye is not a corporate project, but for the average street Joe who plays with RPis and SBCs or is getting into Linux on PCs and has a few IP or PiCams laying around. Corporate developers and programmers seem to not think about how a product is used, they write for a corporate environment, not a home environment.
Maybe a bad analogy, but think about a dishwasher. What if you had to have a BUNCH of devices to do the same job as the single dishwasher? A machine to do the pre-rinse, a device to do the primary wash cycle, a device to do a final rinse, a device to do a sanitizing rinse? Would you buy all those devices or a single device?
My contribution to the previous version of motionEye was to support the end user (mostly street Joe), with testing to determine if their issue was Bug or PEBKAC, bad documentation, or something else. If I wasn't able to tell up front, I tried to reproduce the issue, and point it in the right direction. In the process, some things were simplified and better documented. I found ways around the pip2 issue and included them to extend the longevity of the project.
I've been digging into the docker image issue to get it out of Debian 9 and up to Debian 10 (and soon Debian 11, maybe) and into motion 4.3.2. because I think this is a better product than most of the other options out there.
IMO split containers is overkill here and causes more issues (complexity for users) than what it may solve (the ability to update it independently of motionEye). Also AFAIK motionEye executes motion directly and accesses its config file, so it isn't possible.
Y'know, I just found a reason to possibly split motionEye from motion from motionEye, however, I still do not think it's a "Good Idea"(tm) for Joe Average-user, and that is the Hub Only functionality (no motion detection, but to control and view other motionEye Cameras. There isn't any motion detection capability, or transmogrifying video capability... Again, I don't think this is a needed option for motionEye...
https://github.com/motioneye-project/motioneye/wiki/Installation#the-motion-daemon
https://pypi.org/project/motioneye-client also exists.
Not a CCrisan project, or motionEye project. There are a number of unofficial apps for phones, too...
the Hub Only functionality
If one wants that, then one obviously wants things to be split explicitly for some reason, and in this case Docker may not be the preferred solution anyway. IMHO our Docker image should cover the average case and address especially the users who want to spin up motionEye as fast and easy as possible, which is a single container image so you can do docker run are things are working.
I reviewed all open pull requests now. Some became obsolete in the meantime (closed), some partly (asked for rebase), some are quite nice and seem safe to apply (asked for rebase and in case asked for review from some of you guys), some merged already, some require further work (converted to draft).
I hope we get outstanding replies soon, so rebases are done and we can review and in case merge those. If you guys find time to answer the review requests, that would be great, so in case we can merge what is ready from my end.
I'm quite happy to see, that there it nothing really depending or affected much by the move to Python 3. Most conflicts are due to extra moved to motioneye sub directory and utils.py + handlers.py being split into dedicated files, but on first view it doesn't look too complicated to migrate the changes over.
For docker, would be nice to merge with https://github.com/hassio-addons/addon-motioneye and have an official addon.
You mean to use the same Dockerfile? They install Mosquitto, Nginx, a whole build essential stack (for compiling motion, at least) and other things which seem unnecessary for our needs, while there may be some reason for this for a Home Assistant addon. Also they use the ghcr.io/hassio-addons/base/amd64 base container which may contain other things we do not need.
I think HA guys will know best what a HA addon requires while we know better what a standalone motionEye container requires 😉.
I'll do a suggestion for more generic install instructions soon, which may then serve as basis for the motioneye_init script, Dockerfile, Wiki and README, to align everything as much as possible. In theory, everything, including CI, could use motioneye_init then.
Of course what I meant was to minimize the differences to allow simpler upgrades and security updates.
Not have the same image.
I'd say this is more on the HA addon's team to decide how closely to follow our reference instructions. But we can let them know about those, once defined, for the Python 3 release.
I could help provide the necessary configuration for GitHub Actions to build Docker on multiple architectures.
That would be great. I'll add you to the orga and repo as collaborator so you can create branches right here (not requiring a fork).
One other question: Will this be applied to motionEyeOS too, or no?
Since I move recently from MotionEye to motioneyeOS... I'm courious too about the question
The motionEyeOS repository has been moved to this organization as well now, so generally we can take care of it. But what I said above stays valid: First of all we need to concentrate on a stable motionEye release. I'll see when I find time to check about updating motionEyeOS afterwards. But of course, if anyone has more insights/experience with motionEyeOS and is able to create a test version with current motionEye dev branch version, feel free to do so, open pull requests etc. We can add a dev branch for it as well and add more collaborators to it for easier/faster commits and building test images.
I could help with the italian version if you like. Also can provide help on coding or CI
Very welcome. Quick translation update instruction are here. We, from my end at least, plan to switch strings from Esperanto to English, add instructions to the Wiki about how to update translations, and add a GitHub workflow to trigger automatic rebuilds + commits to a PR via command comments.
Generally on contributions at current stage: There are a few pull requests open with smaller changes and also some new features (WebDAV uploads, S3 uploads, and more). It is always great to have some more eyes on the changed code and in case testing it. Generally motionEye can be installed from any GitHub branch, following the install instructions from here and replacing branch and in case owner of the final URL argument for the pip command. Would be great if we could merge the open PRs soon, then make a feature freeze and concentrate on testing, bug fixes and minor polishing for a release 🙂.
I am using last dev version of motioneyeos and last released version of motioneye by @ccrisan , glad this project is alive again!
I wish to help with Chinese translation of UI (natively Chinese simplified, but mostly compatible with Chinese traditional).
We, from my end at least, plan to switch strings from Esperanto to English
Just as a note: I noticed one more reason in favour of this: The machine translation (that is applied when adding translatable strings) works better from English to any language than from Esperanto to any language (probably due to translations between "non-English" languages using English as a middle step).
And for the record, I can do translation to Finnish. But it might be a good idea to try to first get all the UI strings within the translation support.
Also deepl.com (which works MUCH better than Google translator or any other translator I know to generate natural well sounding sentences) supports English but not Esperanto.
but really do you think esperanto worth the effort to translate?
As all strings (aside of possible new ones) are available in Esperanto already, and because I generally like the idea of a non-English plan language, I'd say yes. And we have someone in the team who knows it well + it's easy to translate from English to Esperanto via online translators.
But indeed, it's no ones mothers tongue, so in theory it is aimed to be how we use it currently (the i18n basis), not likely to be used as locale by end users. So when we switch to English as i18n basis, indeed it is left more for personal like or ideological reasons than for a practical user need, I guess. However, it does not hurt, and probably it catches someones interest about what Esperanto is and to learn it 🙂.
Hi, I would like to help in the project. Initially, I could help with the Spanish translation if still required.
That would be great. See short instructions here: #1968 (comment)
Spanish .po (backend) and .js.po (frontend) files can be found here: https://github.com/motioneye-project/motioneye/tree/dev/motioneye/locale/es/LC_MESSAGES
You can use the English translation files to derive the original text, if Esperanto is an issue.
If you need some help translating, create a new issue and i will guide you through the different steps.
Edit: translations are now managed on weblate : https://hosted.weblate.org/projects/motioneye-project/.
We have received several proposals for contributing to the translation of motioneye.
It would be easier for the translators if we interfaced with a translation site.
Personally I have a preference for weblate, which offers free hosting for free projects, and is interfaced with github.
Does everyone agree?
What about GitHub pages?
GitHub pages are static, it's great for documentation, but i don't think we can use it for translations.
I have created a translation project on weblate : https://hosted.weblate.org/projects/motioneye-project/.
Please take a look and tell me what you think about it, what you would like to change.
@MichaIng I would just like to mention, that I don't relay know python. I am just good at web development and backend stuff in languages other than python. You don't need to request me in things only related to python stuff. Sorry, I forget to mention that.
Thanks for the hint, I'll keep that in mind 🙂.
Hi.
Could you suggest regard development, which your current development environment? It is host OS Ubuntu 20 or it is Docker container(s) (and what OS version in container).
So It would be great if you have link on maybe existed instruction of Devkit needed to development.
I'm devops engineer, little bit code scripts on Shell/Python, Docker and etc. Will glad to help as I can.
The Docker image is using Debian Bullseye as base image, I personally do most testing and development on a Debian Bookworm system. Generally, as it's Python 3 and Python 3.7 and later are supported, you are quite flexible.
The automated install and build tests here on GitHub are using the latest GitHub actions Ubuntu runner, which is 20.04 Focal indeed, but as fast as there is a running with 22.04 Jammy available, I aim to migrate.
Hey,
I see 4 checkmarks in the original post and all of them are ticked. But what does that mean? Looks like the new version is still not ready to be released. I am somehow missing the project mission.
Goal of running under python3 has been achieved which I believe is great. Also anyone can contribute to translation of the user interface which I also very much welcome, but what are the actual blockers - is it the ability to run on Raspberry Pi (starting at Pi Zero), translation to at least 3 major languages, working Docker image, better documentation, some amount of testers/testimonials from users or some other things?
@MichaIng could you please present your thoughts? For me the version for a standard x86_64 and v4l camera already does a great job but apparently you have more expectations from the first yet-to-be-released python3-based version of motionEye. Thanks, jose
Goal of running under python3 has been achieved which I believe is great.
Not yet fully reached, there are still a few errors related to the Python 3 transition, at least #2486. Also adding support for motion v4.4 should be added first: #2462
I vote for starting an official beta then, including a pre-release tag here on GitHub an a related (pre-release) upload PyPI.
Here an overview over open issues and PRs attached to the v0.43.0 milestone. Not all are critical for a pre-release, but at least the open PRs should be finished and merged IMO: https://github.com/motioneye-project/motioneye/milestone/1
It's been over 6 months since the take-over, and 4 months since the last message here, I am curious as to the status of development?
I wanted to have #2462 (motion v4.4 support) added first, but as of new full-time job do not find time for it. So I'm fine with doing at least a pre-release/beta to PyPI with current dev stage and forking off a new main primary branch from dev. Checking recent bug reports, it seems overall better than the current stable release, with quite a bunch of bugs solved (not related to Python 2 > 3 move) and features added.
@jmichault
I saw you added a daily upload workflow to the master2 branch, which requires a valid token only to function? https://github.com/motioneye-project/motioneye/blob/python2/.github/workflows/pypi_daily_build.yml
I would vote for not doing daily uploads, but when pushing a release tag here on GitHub. A "pre-release" on GitHub could then be uploaded to PyPI as pre-release (not sure how this is done 😅), and a stable release as stable to PyPI respectively.
I can do/adjust the workflow part with triggers when pushing to release tags, but I'm not familiar with the tools to upload to PyPI.
What should be a priority is to be able to run motioneye on latest Raspberry Pi OS (Bullseye), 64bit preferably.
Buster (previous version) is already deprecated for Home Assistant, and they move quite fast.
It is naturally independent of the underlying OS version. What you might mean is support for the modern RPi DSI camera stack, that works with the DRM/KMS display stack, which is the default since Bullseye: #2425
Jep it makes sense to focus on this as well, but similarly to motion v4.4 support, if we wait until those two are addressed, we provide users with the problematic motionEye v0.42 too long, which doesn't support motion v4.4 and modern RPi camera stack either, and has a large number of additional issues and bugs. So IMO, if there is not someone having time to address the two issues soon, we should start motionEye v0.43 release regardless to provide at least all the bug fixes and features that have been merged until now.
Hello everyone,
I am interested in help with motionEyeOS. I have not much experience with motionEyeOS yet, but I have some experience with thingOS (on which is motionEyeOS based) - I am working on support for PineCube - and I also have experience with Buildroot (on which is thingOS based) - I contributed to Buildroot with few patches and was using it at work for some years.
I would personally turn thingOS or motionEyeOS (or both?) into Buildroot external - mechanism which can drastically reduce code size (because the code with upstream code will stay in separate repository) and is in my opinion easier to sync between project (motioneyeos and thingos) and it is easier to see which files needs to be maintained and which one can be left untouched for the upstream project. We used Buildroot external at my work, I use it in my personal project and it is also used in projects like Home Assistant OS. I already had some discussion with @ccrisan about it in thingOS.
I am mainly interested in motionEyeOS because of PineCube I own (I also have some Rpis, but without cameras so far). I already use motionEye on Pinecube (with motion 4.3.2), but so far only in pure Buildroot (since motionEyeOS is very outdated and also thingOS has too old Python/setuptools to install motionEye).
What do you @ccrisan and others think?
That is great, since I have no experience with thingOS, but motionEyeOS seems to be much used and hence worth to receive a major update based on the new Python 3 based motionEye.
motionEyeOS seems to be aimed to work like a container in the way that it is not intended to be manipulated after installation but shipped with all that is needed for motionEye to run fully featured and motionEye data as only volatile part. So as long as it is not more work to get this done with Buildroot externals than with thingOS, I agree with you. So I think most important question is whether Buildroot ships all required packages OOTB, Python 3, motion, v4l2-utils, ffmpeg, curl, or the libraries we'd otherwise compile them against.
MotionEyeOS is basically fork of thingOS (you can see many merge commits from thingOS to MotionEyeOS). Similar with thingOS, which is fork of Buildroot (again, you can see merge commits from Buildroot in thingOS repository). Buildroot contains massive amount of packages (you can choose which will be included in final image). ThingOS tooks that and added few other packages on top of it (and things like over the air update, easy wifi/ap/bluetooth configuration etc) and MotionEyeOS took thingOS and added some other packages on top. I would keep it like that, only question is if to keep it as fork, or to transform it to Buildroot externals mechanism as I mentioned above.
Development should be cooperated with thingOS, since motionEyeOS is based on this project.
easy wifi/ap/bluetooth configuration etc
Easy network/WiFi configuration at least is something we might want to keep in motionEyeOS.
What I wanted to say or verify is that larger parts of thingOS won't be required in motionEyeOS so that there would be benefit to shorten the fork tail.
... on the other hand I just had a closer look into it and especially the text file based pre-configuration possibilities are nice for headless SBC scenarios, probably other SBC-specific parts. Maybe it causes more work to pull commits from two upstreams (thingOS for changes we want in motionEyeOS as well, and Buildroot) and in case resolve conflicts, compared to keep it as it is? The Buildroot externals transition could be applied to thingOS instead, to gain the benefit for motionEyeOS as well.
Yeah I agree with that. Since @ccrisan is creator of both thingOS and motionEyeOS (and if I understood him right, he plan to get involved in motionEyeOS development in the future again), lets see what is his vision.
My plans with thingOS are to eventually ditch all customizations and rely on vanilla Buildroot with external packages, code, helpers & whatnot. Maintaining forks and merges on each major version update is a PITA and is definitely not the way to go.
However, both motionEyeOS and thingOS have a lot of custom integrations and functionalities that would need to be rewritten (or ditched!) before switching to vanilla Buildroot. The lack of automated tests (or any kind of tests, in fact) makes this part a lot more difficult.
What I'm saying is that the "correct" way IMHO is indeed for both OSes to be plain Buildroots with external stuff, but that's not going to be an easy task.
So you mean, instead of using "Buildroot externals", using an own mechanism to pull vanilla Buildroot and apply customizations? Whether/in how far "Buildroot externals" can simplify this, @sonicpp will be able to answer.
Instead of doing everything in one step, probably it's more realistic to detangle Buildroot code and custom code step-by-step, when one finds time, creating/splitting out build scripts which complement/patch individual parts of vanilla Buildroot? My 2 cents without much insight into the current code structure and build process 😅.
I can help with GitHub actions to test new parts of, or the whole build process, btw, in perspective automate the image generation for motionEyeOS (How was/is this done currently?). Generated images can be also tested by booting them as container (e.g. via systemd-nspawn and QEMU for ARM emulation) and in case of motionEyeOS e.g. whether motionEye is running and the web interface port listening/API responding. But it doesn't include bootloader/kernel/firmware boot stages, of course.
I am not sure about tests since I have not that much experience with that, but at least automated generated images would be cool.
For the Buildroot-external, I think if we start slowly, like modifiing configs for base support of buildroot & buildroot-externals, adding few necessary packages and then adding other scripts etc, it is doable.
When building Buildroot with br2-external, it is required to specify path to the br2-external directory. If I understand it well, for building thingOS we will need Buildroot repository and repository with thingOS Buildroot-external. For MotionEyeOS we will need the same plus repository with MotionEyeOS Buildroot-external - so two br2-externals in total. Question is where to put the helper scripts common for thingOS/motionEyeOS - to the thingOS repository?
@ccrisan Please tell me here, on thingOS issue we discussed or via email if there is something I can help with (like with the conversion to br2-external for example), I will be more than happy.
So you mean, instead of using "Buildroot externals", using an own mechanism to pull vanilla Buildroot and apply customizations? Whether/in how far "Buildroot externals" can simplify this, @sonicpp will be able to answer.
I mean Buildroot + externals. The way it was designed to be used :)
I can help with GitHub actions to test new parts of, or the whole build process, btw, in perspective automate the image generation for motionEyeOS (How was/is this done currently?). Generated images can be also tested by booting them as container (e.g. via systemd-nspawn and QEMU for ARM emulation) and in case of motionEyeOS e.g. whether motionEye is running and the web interface port listening/API responding. But it doesn't include bootloader/kernel/firmware boot stages, of course.
Building Buildroot images is an extremely intensive operation. A considerable computing power is needed and the whole process takes a few hours.
@ccrisan Please tell me here, on thingOS issue we discussed or via email if there is something I can help with (like with the conversion to br2-external for example), I will be more than happy.
I first need to allocate a serious amount of time to plan this move. I have a few projects that rely on thingOS and breaking them is something I reaaaaaaally want to avoid. I will let you know of the plan as soon as I find the necessary time to come up with one.
A considerable computing power is needed and the whole process takes a few hours.
There bigger the argument to use GitHub actions runners for this 🙂. They don't have much CPU power, so it might even take longer, but no own hardware is blocked 🙈.
Just wanted to pop on by and let you know that I'm in the process of translating the Norwegian Bokmål texts. :)
Norwegian Bokmål is now finished.
Hi, I'd like to contribute. Is it possible to add me as a collaborator?
Many thanks for considering to contribute to motionEye. Before it becomes to inflationary, IMO good practice is to add you to the contributors list, after your did some contribution, and not beforehand 🙂. I'm all in for being open and inclusive, but a minimum level of trust building is fine I think.
Development should be cooperated with thingOS, since motionEyeOS is based on this project.
I fully support this, as I'm using thingOS for photOS :-)
Thus, it would be great if improvements to the base software would go upstream (i.e. merged into thingOS).
I might be able to support on the base system. Just @mention me.
A considerable computing power is needed and the whole process takes a few hours.
There bigger the argument to use GitHub actions runners for this slightly_smiling_face. They don't have much CPU power, so it might even take longer, but no own hardware is blocked see_no_evil.
@MichaIng Feel free to have a look at https://github.com/avanc/photOS/tree/master/.github/workflows
I'm building photOS for 4 platforms (RaspberyPi 1-4) in parallel based on git tags.
But there might be potential for optimization. Sometimes I hit the GuthubActions time limit...
You mean to merge improvements from photOS into thingOS? I suggest to open PRs in this case.
However, I'm the wrong person to discuss about thingOS 😉.
My intention was to use the photOS Github workflow as starting point for automatic compilation of motioneyos :-)
Ah, in with my first comment I meant to port improvements from motioneyeos back to thingOS, so photOS can also benefit from it ;-)
Any thought about switching Motion to Motionplus?
I just gave up on Motioneye and Motion for my new Rasperry Pi Camera V3. I have not got any of the workarounds to work. Motionplus works but the GUI is lacking. Switching to Motionplus will give good support for libcamera.
Any thought about switching Motion to Motionplus?
I just gave up on Motioneye and Motion for my new Rasperry Pi Camera V3. I have not got any of the workarounds to work. Motionplus works but the GUI is lacking. Switching to Motionplus will give good support for libcamera.
Yeah good luck with that. I think you should very much look forward to the Python 3 port at the moment, that's the most important thing right now AFAIK.
is there an ETA on the next release?
seems to be taking forever
Not really. To speed things up, would be great if someone could write release notes. Then I'll merge #2675 to push a pre-release to PyPI.
If I correct understand, that now migration on Python3 is actually nothing happening (just a translation to other languages) ?
Could you rephrase your question? I do not understand.
Multi-language support is probably the most visible change aside of the Python 2 to Python 3 migration. But there were a lot of other changes and fixes, especially around the upload options and methods. Check out the list of merged PRs with the milestone assigned: https://github.com/motioneye-project/motioneye/pulls?q=is%3Apr+is%3Aclosed+milestone%3Av0.43.0
@MichaIng , you answered on my question actually, this is what i meant, thank you.
Do you have documentation on CI/CD part or it's CI files only?
Thanks.
@MichaIng Happy to see that motioneye lives on and gets the well deserved Python 3 migration! Thanks for your work everyone 😃
With a new team at the helm and new features already added or in the works, I was wondering if there was any interest in this functionality I requested to merge five years ago now: #821
At the time Calin didn't want to merge it because it adds pynacl as a new dependency and he expected most users to not be interested in encrypting media files uploaded to the cloud by motioneye or using separate tooling for that.
If you as the team are interested, please let me know and I'll gladly make a new PR. I've been using the functionality for 5 years now and still think it's a nice feature :)
Aside from that, are there any technical blockers remaining for the 0.43.0 release or is the list of issues assigned to the milestone representative of all the work left? Maybe I can help with something.
@beppo-dd You have created no issues and no pull requests. Why should you be named as a project maintainer?
https://github.com/motioneye-project/motioneye/issues/created_by/beppo-dd
https://github.com/motioneye-project/motioneye/pulls?q=is%3Apr+author%3Abeppo-dd
@cclauss This was of course not my intention.
My question arose because I wanted to correct a wiki page in motioneyeos, but I couldn't find any ways to edit it: In Github, there is no way to do pull requests on other wiki pages, see #846. I can clone the wiki repository, but I have no right to write on it, see this answer of the stackoverflow question "On GitHub, can I fork … a wiki".
Question: Can I get a possibility to correct the wiki page that belongs to the motioneyeos reposity?
Now I understand. Let's try this approach.
Let's say that you want to make edits to wiki/Manual-Download-And-Installation
- Make a new pull request with the file
wiki-edits/Manual-Download-And-Installation.md - Your first commit should be exactly the same text as the wiki file but with two modifications to the filepath.
- Add
-editsto the directory name. - Add
.mdas the file name suffix.
- Add
- Your second (and later) commits should be your desired changes.
- This pull request will never be merged but if a maintainer finds the modifications useful then they may choose to transfer them to the corresponding wiki page.
Leaving the first commit be the wiki page unmodified will allow maintainers to spot exactly what was changed.
I hope this process makes sense.
@cclauss I hope, I did it right: see motioneye-project/motioneyeos/pull/2998.
Please be sure to read my "Warning" at the end of the pull request description.
Good morning,
Do you still need help in coding, git ops (mergin, rebasing...) and so on?
Specifically on the migration to Py3, I might be of help. Anyhow, any news on its release?
@theGiuMac Python 2 died 1,372 days ago on 1/1/2020.
It is therefore a shame that the default branch of this repo still points to a Python 2 implementation.
If you are interested in this functionality, please look at the dev branch instead. It is 800+ commits ahead of the default.