Releases retrieved: 22.06.0-beta.0 Upstream release that is considered latest: 22.06.0-beta.0 Current version/release in rawhide: 20.10.16-1.fc37 URL: https://github.com/moby/moby Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/11719/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/moby-engine
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
Releases retrieved: 23.0.0-rc.1 Upstream release that is considered latest: 23.0.0-rc.1 Current version/release in rawhide: 20.10.21-1.fc38 URL: https://github.com/moby/moby Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/11719/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/moby-engine
Releases retrieved: 23.0.0 Upstream release that is considered latest: 23.0.0 Current version/release in rawhide: 20.10.23-1.fc38 URL: https://github.com/moby/moby Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/11719/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/moby-engine
Releases retrieved: 23.0.1 Upstream release that is considered latest: 23.0.1 Current version/release in rawhide: 20.10.23-1.fc38 URL: https://github.com/moby/moby Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/11719/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/moby-engine
*** Bug 2168864 has been marked as a duplicate of this bug. ***
Any changes here? I've tried to checkout from src to open a PR, but seems I need more permissions? :)
you have anonymous option fedpkg clone [-h] [--branches] [--branch BRANCH] [--anonymous]
Thanks, haven't had chance to try it yet. Would that allow opening a PR as well? Also, is there any movement on getting 23.0.1 build? What are current blockers?
(In reply to Marko Bevc from comment #9) > Thanks, haven't had chance to try it yet. Would that allow opening a PR as > well? > > Also, is there any movement on getting 23.0.1 build? What are current > blockers? you have a lot to learn, general documentation: https://docs.fedoraproject.org/en-US/package-maintainers/ you need essentially https://docs.fedoraproject.org/en-US/package-maintainers/Installing_Packager_Tools/ i.e.You must have one Fedora Accounts System and You also must have an ssh key configured in the Fedora Accounts System to be able to make changes to any package, including your own.
Thanks for sending the links and your hlep. Just a note on general docs, some links are dead or outdated. I'll give packaging tools a go and set up SSH. I think lowering the barrier to entry and more concise docs would be beneficial to open this up to more folks.
fedpkg clone moby-engine cd moby-engine fedpkg fork git fetch $your_user_name git branch -u $your_user_name/rawhide edit moby-engine.spec fedpkg mockbuild -N (to build locally) or fedpkg scratch-build --srpm when it is ready : git commit . git push and in fork webpage something like https://src.fedoraproject.org/fork/your_user/rpms/moby-engine , do the pull request please Thank you
Releases retrieved: 23.0.2 Upstream release that is considered latest: 23.0.2 Current version/release in rawhide: 20.10.23-1.fc38 URL: https://github.com/moby/moby Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/11719/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/moby-engine
Scratch build failed. Details below: DownloadException: The specfile contains a Source URL with an unknown protocol; it shouldbe "https", "http", or "ftp". Traceback: File "/usr/local/lib/python3.10/site-packages/hotness/use_cases/package_scratch_build_use_case.py", line 56, in build result = self.builder.build(request.package, request.opts) File "/usr/local/lib/python3.10/site-packages/hotness/builders/koji.py", line 164, in build new_sources = self._spec_sources(specfile, tmp) File "/usr/local/lib/python3.10/site-packages/hotness/builders/koji.py", line 337, in _spec_sources raise DownloadException(msg) If you think this issue is caused by some bug in the-new-hotness, please report it on the-new-hotness issue tracker: https://github.com/fedora-infra/the-new-hotness/issues
Releases retrieved: 20.10.24 Upstream release that is considered latest: 23.0.2 Current version/release in rawhide: 20.10.23-1.fc38 URL: https://github.com/moby/moby Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/11719/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/moby-engine
Releases retrieved: 23.0.3 Upstream release that is considered latest: 23.0.3 Current version/release in rawhide: 20.10.23-1.fc38 URL: https://github.com/moby/moby Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/11719/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/moby-engine
Is there any reason this is held back at the moment? I am using SilverBlue with moby-engine right now and I have to pin a 2 year old docker-compose version to get my development environments working.
The old docker-compose is a separate issue. We don't have docker-compose v2 packaged. In the interim, it's possible to install the docker-compose binary (you can download the build from Github Releases or build it yourself from source) into ~/.docker/cli-plugins [1] and use it alongside moby-engine. The package hasn't been updated due to lack of time. One of the maintainers (or really anyone else who wants to work on it) will have to make the necessary packaging changes and submit a PR. [1] https://github.com/docker/compose#where-to-get-docker-compose
Ty, I already installed it via alternate ways and started out with the v2.x releases which sadly did not work. I guess it's a matter of time then, thanks!
> I already installed it via alternate ways and started out with the v2.x releases which sadly did not work. Out of curiosity, what was the exact issue?
The server version for Docker (moby-engine) 20.10 and the match of docker-compose v2.x results in me not being able to run any commands at all when bringing containers up, which works just fine with 1.29.2 (current version in the repos) ❯ docker-compose -f docker-compose.yml -f docker-compose.dev.yml up --build # docker-compose 1.29.2 [...] Successfully tagged full-stack-boilerplate_client:latest Creating client ... done Creating database ... done Creating app ... done When 'mismatching' docker-compose v2.x with moby-engine 20.10 it cannot build the containers ❯ docker compose version Docker Compose version v2.16.0 ❯ docker compose -f docker-compose.yml -f docker-compose.dev.yml up WARN[0000] The "ENCRYPTION_KEY" variable is not set. Defaulting to a blank string. WARN[0000] The "URL" variable is not set. Defaulting to a blank string. [+] Building 0.7s (10/28) => [full-stack-boilerplate-api internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 1.11kB 0.0s => [full-stack-boilerplate-client internal] load build definition from Dockerfile 0.1s => => transferring dockerfile: 1.11kB 0.0s => [full-stack-boilerplate-api internal] load .dockerignore 0.1s => => transferring context: 2B 0.0s => [full-stack-boilerplate-client internal] load .dockerignore 0.1s => => transferring context: 2B 0.0s => [full-stack-boilerplate-client internal] load metadata for docker.io/library/ubuntu:20.04 0.0s => [full-stack-boilerplate-client base 1/15] FROM docker.io/library/ubuntu:20.04 0.0s => CANCELED [full-stack-boilerplate-api internal] load build context 0.4s => => transferring context: 51.23MB 0.3s => CACHED [full-stack-boilerplate-client base 2/15] WORKDIR /usr/bot 0.0s => ERROR [full-stack-boilerplate-api base 3/15] RUN apt update 0.5s => CANCELED [full-stack-boilerplate-client internal] load build context 0.4s => => transferring context: 48.18MB 0.3s ------ > [full-stack-boilerplate-api base 3/15] RUN apt update: #0 0.370 exec /bin/bash: permission denied ------ failed to solve: executor failed running [/bin/bash -l -c apt update]: exit code: 1 As I said it's working fine with using the current repo version of docker-compose so I can get around it :)
I think that error is because of SELinux and not anything to do with the version of moby-engine you have installed. That's a known issue: https://bugzilla.redhat.com/show_bug.cgi?id=2106319. Someone will have to work with the container-selinux maintainers to update the policy.
Very well, thank you for the pointer. I will keep a watch on that issue then, thanks for taking the time to respond!
pull request are welcome see comment #12
I was trying to follow the instructions but I was not able to clone the repository. Insufficient rights to do so
Managed to get further using (mixing) the instructions in #12 and https://docs.fedoraproject.org/en-US/package-maintainers/Package_Maintenance_Guide/#using_fedpkg_anonymously and https://docs.fedoraproject.org/en-US/package-maintainers/Installing_Packager_Tools/. It is currently stuck on the following build step: + man/md2man-all.sh /var/tmp/rpm-tmp.9ZcDzX: line 141: man/md2man-all.sh: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.9ZcDzX (%build) Possibly this dependency is reeled in from cli-${version}/vendor.conf however this is not present in v23 ❯ find ./* -name "vendor.conf" ./vendor/github.com/docker/distribution/vendor.conf ❯ git checkout v20.10.23 Previous HEAD position was f480fb1e37 Merge pull request #4202 from thaJeztah/23.0_backport_docs_daemon_proxy_config HEAD is now at 715524332f Merge pull request #3979 from thaJeztah/20.10_backport_docs_ps_size ❯ find ./* -name "vendor.conf" ./vendor/github.com/containerd/containerd/vendor.conf ./vendor/github.com/docker/distribution/vendor.conf ./vendor/github.com/docker/docker/vendor.conf ./vendor/github.com/docker/swarmkit/vendor.conf ./vendor.conf It seems to be replaced with the vendor.sum file which is formatted differently.. The closet thing I can find is https://github.com/moby/moby/blob/v23.0.4/vendor.sum, I am blocked with this issue right now. I have the local copy only as of now. It seems the last item of the build process seems to go wrong, what item spawns the man/md2man-all.sh? I can't see the folder it's trying to call with the upgrade to 23.x locally mv $WORK/b001/exe/a.out ../_build/bin/docker rm -r $WORK/b001/ + man/md2man-all.sh /var/tmp/rpm-tmp.pfFz0R: line 141: man/md2man-all.sh: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.pfFz0R (%build)
vendor.conf seems to be superceded by vendor.mod
Due to insufficient rights I can't continue, I got past the install phase and am having some trouble with the docs generation (the %doc lines). I can't push to the fedora source repo, where do you want me to upload the work done to be further iterated upon?
please also read comment #8 and comment #10
Build is passing locally now, the %docs row still had some phased out .md file specified in there. Doing another build to be sure and going to try to get that on to the remote fork i created
Releases retrieved: 23.0.4 Upstream release that is considered latest: 23.0.4 Current version/release in rawhide: 20.10.23-1.fc38 URL: https://github.com/moby/moby Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/11719/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/moby-engine
Everything is ready locally, I cant seem to push to it to the remote repos. How to proceed further?
Managed to create the PR and push the changes, please see https://src.fedoraproject.org/rpms/moby-engine/pull-request/18
(In reply to John from comment #36) > Managed to create the PR and push the changes, please see > https://src.fedoraproject.org/rpms/moby-engine/pull-request/18 nice , I going update the package
Hey all. Thank you for working on this! Do the new version(s) of Moby introduce breaking changes? Would we only be able to put this new version in F39+ ?
(In reply to John from comment #35) > Everything is ready locally, I cant seem to push to it to the remote repos. > How to proceed further? you found it :) I fixed update.sh https://src.fedoraproject.org/rpms/moby-engine/c/f3ca1f3ff331ded358985ff07ecda47127c1c9e9?branch=rawhide (In reply to Dusty Mabe from comment #38) > Hey all. Thank you for working on this! > > Do the new version(s) of Moby introduce breaking changes? Would we only be > able to put this new version in F39+ ? moby-engine is a leaf package I will build it for F37+ , not sure if going update F36 Thanks
Awesome I see it's merged in https://src.fedoraproject.org/rpms/moby-engine/c/f3ca1f3ff331ded358985ff07ecda47127c1c9e9?branch=rawhide, how will the testing process be picked up further?
FEDORA-2023-b060afab31 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-b060afab31
Installed the RPM from the builds locally on a Workstation VM and I don't see any issues for any of my docker projects.
FEDORA-2023-f0bb213148 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-f0bb213148
Tested it with some other docker projects, seems like BuildKit enabled projects are not playing nice with the new version. BuildKit is enabled but the buildx component is missing or broken. Should we bundle this with moby-engine?
We probably need a seperate build/install step to install https://github.com/docker/buildx/tree/v0.10.4 which I am not too knowledgable about.
Nice work, thanks! (couldn't find time here unfortunately) If it's enabled I think we probably should or at least provide a package for it.
That works as well, would only require the spec file to add an install dependency which would be more ideal
Docker provides it as a different package, so I think it's best to seperate buildx as a seperate package and include it as a dependency in moby-engine.
I agree and it makes sense to me.
FEDORA-2023-f0bb213148 has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-f0bb213148` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-f0bb213148 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-b060afab31 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-b060afab31` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-b060afab31 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
mkdir golang-github-docker-buildx cd mkdir golang-github-docker-buildx go2rpm https://github.com/docker/buildx spectool -g golang-github-docker-buildx.spec fedpkg mockbuild -N DEBUG util.py:443: No matching package to install: 'golang(github.com/compose-spec/compose-go/dotenv)' DEBUG util.py:443: No matching package to install: 'golang(github.com/compose-spec/compose-go/loader)' DEBUG util.py:443: No matching package to install: 'golang(github.com/compose-spec/compose-go/types)' DEBUG util.py:443: No matching package to install: 'golang(github.com/docker/cli-docs-tool)' DEBUG util.py:443: No matching package to install: 'golang(github.com/docker/cli-docs-tool/annotation)' DEBUG util.py:443: No matching package to install: 'golang(github.com/hashicorp/go-cty-funcs/cidr)' DEBUG util.py:443: No matching package to install: 'golang(github.com/hashicorp/go-cty-funcs/crypto)' DEBUG util.py:443: No matching package to install: 'golang(github.com/hashicorp/go-cty-funcs/encoding)' DEBUG util.py:443: No matching package to install: 'golang(github.com/hashicorp/go-cty-funcs/uuid)' DEBUG util.py:443: No matching package to install: 'golang(github.com/moby/buildkit/client/connhelper/ssh)' DEBUG util.py:443: No matching package to install: 'golang(github.com/moby/buildkit/frontend/subrequests/outline)' DEBUG util.py:443: No matching package to install: 'golang(github.com/moby/buildkit/frontend/subrequests/targets)' when it builds you may submit a package review request with fedora-create-review man fedora-create-review btw see https://bugzilla.redhat.com/show_bug.cgi?id=2159979#c12 , we will need also the same packages btw also we need update - golang-github-containerd-cgroups to 3.0.1 - golang-github-docker-slim to 1.40.1 - golang-github-docker, golang-github-moby-swarmkit-2 and golang-github-hashicorp-consul I guess
Working on a way to package buildx now, what are the type of SHA sums used. Or can I pick any of 256/512?
No luck, can't resolve the golang pacakge not resolving as there is no vendor.conf file in the buildx repo. Is there any other we can have a go at this? I tried locally cloning and checking out tags and tarring them/md5summing them. I put my work here, currently blocked if anyone has any ideas https://pagure.io/golang-github-docker-buildx/tree/master
Maybe packaging the 4 root packages will help? I am not sure mkdir golang-github-compose-spec-compose-go go2rpm --dynamic-buildrequires github.com/compose-spec/compose-go/ --no-rpmautospec # Change the package name in vim to account for the full name it only goes to the compose-spec part? Repeat the same for github.com/docker/cli-docs-tool github.com/hashicorp/go-cty-funcs github.com/moby/buildkit etc. Any thoughts on this?
When building the docker packages it shows cyclic dependencies, I guess we will have to fix it in the root repository.... Package go-rpm-macros-3.2.0-2.fc38.x86_64 is already installed. No matching package to install: 'golang(github.com/docker/buildx/commands)' No matching package to install: 'golang(github.com/docker/buildx/driver/docker)' No matching package to install: 'golang(github.com/docker/buildx/driver/docker-container)' No matching package to install: 'golang(github.com/docker/buildx/driver/kubernetes)' Package golang-github-docker-cli-devel-22.06.0~beta.0-2.fc38.noarch is already installed. Package golang-github-spf13-cobra-devel-1.6.1-2.fc38.noarch is already installed. Package golang-github-spf13-pflag-devel-1.0.5-12.20220918gitd5e0c06.fc38.noarch is already installed. Package golang-github-stretchr-testify-devel-1.8.0-4.fc38.noarch is already installed. Package golang-github-stretchr-testify-devel-1.8.0-4.fc38.noarch is already installed. Reading the Fedora docs didn't give any new insights as well, maybe I am overlooking something https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/
Hi, > what are the type of SHA sums used ? if you are asking how is made sources files , it can be made with `fedpkg new-sources buildx-0.10.4.tar.gz --offline` since you already have a fas username , you can login with it in https://chat.fedoraproject.org/ and join on room golang ( #golang:fedoraproject.org ) I know very little about go lang
(In reply to John from comment #56) I see , you got an example of bootstrap here https://src.fedoraproject.org/rpms/golang-github-docker/blob/rawhide/f/golang-github-docker.spec
Created a merge request for the update of golang-github-containerd-cgroups to 3.0.1 in https://src.fedoraproject.org/rpms/golang-github-containerd-cgroups/pull-request/1
docker-slim is failing on + rm -rf docker-slim-1.40.1 + /usr/lib/rpm/rpmuncompress -x /builddir/build/SOURCES/docker-slim-1.40.1.tar.gz + STATUS=0 + '[' 0 -ne 0 ']' + cd docker-slim-1.40.1 /var/tmp/rpm-tmp.Ct17Go: line 39: cd: docker-slim-1.40.1: No such file or directory
(In reply to John from comment #60) > docker-slim is failing on > > + rm -rf docker-slim-1.40.1 > + /usr/lib/rpm/rpmuncompress -x > /builddir/build/SOURCES/docker-slim-1.40.1.tar.gz > + STATUS=0 > + '[' 0 -ne 0 ']' > + cd docker-slim-1.40.1 > /var/tmp/rpm-tmp.Ct17Go: line 39: cd: docker-slim-1.40.1: No such file or > directory been there, done that , and don't know the solution I have finished build golang-github-docker-23.00.4-1.20230420gitv23.0.4.fc39.src.rpm
Okay great, that leaves golang-github-moby-swarmkit-2 and golang-github-hashicorp-consul. Going to work on golang-github-hashicorp-consul I guess
hashicorp-consul done https://src.fedoraproject.org/rpms/golang-github-hashicorp-consul/pull-request/1
We have new upstream release we might want to rebase to: https://github.com/moby/moby/releases/tag/v23.0.5
We can do that later, should not be as much of an issue now that the build is working for v23.x. I think Sergio is working on updating the dependencies first for moby-engine v23
moby/moby is on tag 24.0.1 now. I don't see any big difference between 23. Maybe an idea to bump it up to 24.x and skip the 23 series if no issues arise?
Given that @sergio gets the packages required for v23.x in the fedora repos ofcourse
We have 23.x in rawhide, which means it will be delivered with F39. Is everything in rawhide at least in a good enough state to ship for F39?
We still have some roadblocks that are above my paygrade, Sergio has been gradually working on getting them fixed (it involves alot of new packages due to Go being silly). As of now it's sorta functional but some edge cases I tested are not passing yet. You can try and give it a shot using the COPR https://copr.fedorainfracloud.org/coprs/sergiomb/docker3 and report back any findings/contribute. If you need a starting point for testing you can use the https://github.com/docker/awesome-compose/ repo and see what issues you can find.
Thanks for the info John. I don't personally use moby-engine, but Fedora CoreOS (the group I represent) does have moby-engine/docker users, which is why I asked the question above. I'm wondering how bad the missing pieces are? i.e. would some users consider it to be huge regression if they updated to F39 with the new 23.x moby-engine that's shipping there now?
It would be, when running docker-compose layers and trying to run a project with a mysql layer the file permissions etc are not set correctly so it would be a huge regression.