New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
media-libs/lib3mf 2.1.0: version bump #19412
Conversation
Pull Request assignmentSubmitter: @waebbl media-gfx/openscad: Linked bugsBugs linked: 769275 In order to force reassignment and/or bug reference scan, please append Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide |
Pull request CI reportReport generated at: 2021-02-11 08:20 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
Switching openscad live ebuild to use cmake instead of qmake. Works with both, lib3mf-1.8.1 and lib3mf-2.1.0. Latter needs a patch due to a case change from lib3MF.pc to lib3mf.pc. |
For the act dependency needed to re-add keywords for x86 and arm see #19411 |
Pull request CI reportReport generated at: 2021-02-13 10:25 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
Pull request CI reportReport generated at: 2021-03-01 23:30 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
Is the act dependency still needed? Can we somehow combine this PR with #19714? |
Actually could you combine all the related work to a single PR. I'm at loss, and am fearing there'll be tree breakage or unnecessary rebuilds for users. Openscad is not a little package. |
@juippis Sure, I can combine them in a single PR. The act package is 'only' needed to get x86 and arm keywords back to lib3mf. For amd64 the included binary does the job. Should I add it to the PR too? |
Up to you, I quickly glanced at the ebuild and it might need .. a lot of fixes before it can be pushed. So maybe best to leave it out for now. |
Yes it might need some rework. The point with the package is, that upstream doesn't follow the usual way Go packages are developed, so the Go eclasses don't seem to be useful. On the other hand the build is rather trivial, so I decided for the way it's done. |
I've nearly caught up with our PR work queue, please ping me in ~a week from now for the act package and I'll take a look. |
Closes: https://bugs.gentoo.org/769275 Package-Manager: Portage-3.0.14, Repoman-3.0.2 Signed-off-by: Bernd Waibel <waebbl-gentoo@posteo.net>
This package version does not build against lib3mf-2 API. Package-Manager: Portage-3.0.14, Repoman-3.0.2 Signed-off-by: Bernd Waibel <waebbl-gentoo@posteo.net>
Now uses cmake instead of qmake. Package-Manager: Portage-3.0.14, Repoman-3.0.2 Signed-off-by: Bernd Waibel <waebbl-gentoo@posteo.net>
Bug: https://bugs.gentoo.org/773217 Closes: https://bugs.gentoo.org/769278 Package-Manager: Portage-3.0.16, Repoman-3.0.2 Signed-off-by: Bernd Waibel <waebbl-gentoo@posteo.net>
Pull request CI reportReport generated at: 2021-03-06 23:50 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me know the answers to my questions, there's no need for you to do anything, I can fix those minor issues while merging.
@@ -46,7 +46,7 @@ RDEPEND=" | |||
media-libs/freetype | |||
>=media-libs/glew-2.0.0:0= | |||
media-libs/harfbuzz:= | |||
media-libs/lib3mf | |||
<media-libs/lib3mf-2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will the update cause runtime issues? Ie should this be revbumped for this...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2019.05 will not build with lib3mf-2. Lib3mf-2 has been released after 2019.05 and support for it has not been backported
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea is, people who have 2019.05-r4 installed now will update to lib3mf-2, because the restriction won't hit their package database before a rebuild. So, if lib3mf-2 will cause runtime issues to openscad-2019.05, this ebuilds needs t obe revbumped so that won't happen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As the package won't build with lib3mf-2 I suspect it will cause runtime issues, whenever someone tries to im-/export a 3mf format file.
I'm gonna revbump the package then.
media-libs/freetype | ||
>=media-libs/glew-2.0.0:0= | ||
media-libs/harfbuzz:= | ||
media-libs/lib3mf |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this work with both 1 and 2? Is some restriction needed? That's also why I asked to combine the PRs so that no modification is needed for this version after merging.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new version works with both lib3mf versions.
Closes: https://bugs.gentoo.org/769275
Package-Manager: Portage-3.0.14, Repoman-3.0.2
Signed-off-by: Bernd Waibel waebbl-gentoo@posteo.net
Current versions of media-gfx/openscad don't work with this API version and need to be restricted to <lib3mf-2. The upcoming openscad version bump does work with it. See
Bug: https://bugs.gentoo.org/769278