Skip to content

Conversation

NathanMOlson
Copy link

Update to latest upstream version of draco.

I plan to follow up this PR with this one:

NathanMOlson#1

@pierotofy I'd like to submit this to the upstream repo google/draco, which requires signing the Google Individual Contributor License Agreement. Does that sound good to you? This is based on your work.

andreasplesch and others added 26 commits February 1, 2023 13:50
after it was removed a few years ago in the update to 1.4.0
* Draco v1.5.6 release.
file_writer_utils.cc - fix preprocessor check and wrong path check
draco_options.cmake - add DRACO_INSTALL option; draco_install.cmake - check DRACO_INSTALL before adding install rules

Co-authored-by: Ondrej Stava <[email protected]>
* Draco 1.5.7 release.
* add .github/dependabot.yml

This attempts to group all security related fixes for docs/ gems
into one PR on a monthly basis.

* clear yamllint warnings

ignoring 'document-start'
Bumps [nokogiri](https://github.com/sparklemotion/nokogiri) from 1.13.6 to 1.15.5.
- [Release notes](https://github.com/sparklemotion/nokogiri/releases)
- [Changelog](https://github.com/sparklemotion/nokogiri/blob/main/CHANGELOG.md)
- [Commits](sparklemotion/nokogiri@v1.13.6...v1.15.5)

---
updated-dependencies:
- dependency-name: nokogiri
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Ondrej Stava <[email protected]>
Bumps the bundler group with 1 update in the /docs directory: [activesupport](https://github.com/rails/rails).


Updates `activesupport` from 4.2.10 to 5.2.8.1
- [Release notes](https://github.com/rails/rails/releases)
- [Changelog](https://github.com/rails/rails/blob/v7.1.3.4/activesupport/CHANGELOG.md)
- [Commits](rails/rails@v4.2.10...v5.2.8.1)

---
updated-dependencies:
- dependency-name: activesupport
  dependency-type: indirect
  dependency-group: bundler
...

Signed-off-by: dependabot[bot] <[email protected]>
…ndler-84ab342b8a

Bump activesupport from 4.2.10 to 5.2.8.1 in /docs in the bundler group across 1 directory
Bumps [github-pages](https://github.com/github/pages-gem) from 217 to 220.
- [Release notes](https://github.com/github/pages-gem/releases)
- [Commits](github/pages-gem@v217...v220)

---
updated-dependencies:
- dependency-name: github-pages
  dependency-type: direct:development
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Using `bundle update --all`. This may get a better baseline for
Dependabot in the future; recent runs failed due to mixed dependency
requirements.
Using `bundle update --all`. This may get a better baseline for
Dependabot in the future; recent runs failed due to mixed dependency
requirements:

```
Bundler::SolveFailure with message: Could not find compatible versions

Because github-pages >= 224 depends on jekyll-seo-tag = 2.8.0
  and jekyll-seo-tag >= 2.8.0 depends on Ruby >= 2.5.0,
  github-pages >= 224 requires Ruby >= 2.5.0.
So, because Gemfile depends on github-pages >= 231, <= 232
  and current Ruby version is = 2.4.1,
  version solving has failed.
```
This should address recent Dependabot failures:

```
Bundler::SolveFailure with message: Could not find compatible versions

Because github-pages >= 224 depends on jekyll-seo-tag = 2.8.0
  and jekyll-seo-tag >= 2.8.0 depends on Ruby >= 2.5.0,
  github-pages >= 224 requires Ruby >= 2.5.0.
So, because Gemfile depends on github-pages >= 231, <= 232
  and current Ruby version is = 2.4.1,
  version solving has failed.
```
notably webrick, which should address a dependabot security warning
after:
049616e docs/.ruby-version: bump version to 2.5.0
doc/Gemfile.lock: update deps
'include: "scope"' should list the dependencies update in the commit.
This is the latest release and <= 3.1 are already end of life [1]. 3.2
will be EOL after March 2026.

[1]: https://endoflife.date/ruby
Rather than gcc-10 / g++-10; the Ubuntu-latest image does not have this
installed and defaults to gcc 13.
Notably nokogiri, which should resolve dependabot warnings related to
open CVEs for the library.
Fixes `-DDRACO_TRANSCODER_SUPPORTED=1` build with newer versions of gcc
(reproduced with 13 in the github workflow & 14 locally):

```
In file included from src/draco/io/gltf_utils.cc:15:
src/draco/io/gltf_utils.h:35:29: error: expected ')' before 'value'
   35 |   explicit GltfValue(uint8_t value)
      |                     ~       ^~~~~~
      |                             )
src/draco/io/gltf_utils.h:41:30: error: expected ')' before 'value'
   41 |   explicit GltfValue(uint16_t value)
      |                     ~        ^~~~~~
      |                              )
src/draco/io/gltf_utils.h:44:30: error: expected ')' before 'value'
   44 |   explicit GltfValue(uint32_t value)
      |                     ~        ^~~~~~
      |                              )
```
@pierotofy
Copy link
Member

I'm not willing to personally sign a CLA with Google, but I hereby assign you the permission to take my commit 3e768dd and to co-own it.

I can recommend to target a new branch 357 so that old versions of ODM don't get a different version of draco when this gets merged.

@NathanMOlson
Copy link
Author

I'm not willing to personally sign a CLA with Google, but I hereby assign you the permission to take my commit 3e768dd and to co-own it.

OK, thanks. I'll submit that upstream and see if it goes anywhere.

I can recommend to target a new branch 357 so that old versions of ODM don't get a different version of draco when this gets merged.

OK. I don't see a way for me to target a nonexistent branch. Is that something I can do, or do I need one of the repo owners to create that branch for me?

What do you think of using a single ODM branch to track the changes from upstream? Then we can use commit hashes or git tags to specify versions instead of the branch name. I think this would make it easier to maintain a long-lived fork, compared to creating a new branch every time we sync with upstream.

@pierotofy pierotofy changed the base branch from master to develop August 10, 2025 04:22
@pierotofy
Copy link
Member

I think that approach works too.

I've retargeted the PR to develop, which is based on 304 (the latest)

Note that as you might have heard, I've recently passed the torch as maintainer of ODM (https://community.opendronemap.org/t/maintainer-needed-for-the-odm-repo/25089/6) so I will not be further handling contributions to repositories related to ODM for the time being. 🙏

cc @smathermather

@NathanMOlson
Copy link
Author

Note that as you might have heard, I've recently passed the torch as maintainer of ODM (https://community.opendronemap.org/t/maintainer-needed-for-the-odm-repo/25089/6) so I will not be further handling contributions to repositories related to ODM for the time being. 🙏

Yes, I did hear that. Your announcement came just as I started playing with ODM, so I hope that was a coincidence and I didn't scare you off with my dramatic build changes :)

Thanks for all your work on this project, it's really amazing.

@pierotofy
Copy link
Member

I hope that was a coincidence and I didn't scare you off with my dramatic build changes :)

Not at all, it was a decision long in the making. But it is an unfortunate timing, as the work you're doing is very useful and I hope this transition won't slow things down too much.

@smathermather
Copy link

I think that approach works too.

I've retargeted the PR to develop, which is based on 304 (the latest)

👍

Note that as you might have heard, I've recently passed the torch as maintainer of ODM (https://community.opendronemap.org/t/maintainer-needed-for-the-odm-repo/25089/6) so I will not be further handling contributions to repositories related to ODM for the time being. 🙏

Yup. @NathanMOlson -- at tag me if I miss something in your pull requests. I think I've got alerts for all the repos, but it's a good just-in-case. I'll also link this back to OpenDroneMap/ODM#1904 so we can keep the overall thread together. I suggest doing that for other pull requests against library forks.

I hope that was a coincidence and I didn't scare you off with my dramatic build changes :)

Not at all, it was a decision long in the making. But it is an unfortunate timing, as the work you're doing is very useful and I hope this transition won't slow things down too much.

Yes. The changes are much appreciated. I'll steward as best I can while working on getting word out for recruiting a maintainter.

@NathanMOlson
Copy link
Author

Superceded by #3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants