Skip to content
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

mayavi-4.4.0.ebuild tested to build with vtk-6 #349

Merged
merged 5 commits into from Jan 22, 2015
Merged

Conversation

jamasi
Copy link
Contributor

@jamasi jamasi commented Jan 18, 2015

I've quickly tested mayavi after build and it seems to be working.

@@ -0,0 +1,76 @@
# Copyright 1999-2013 Gentoo Foundation
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

repoman should have alerted you that this is 2015. Did you use repoman?

test? (
${RDEPEND}
dev-python/nose[${PYTHON_USEDEP}]
dev-python/wxpython[opengl]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing SLOT and PYTHON_USEDEP

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eh? It seems to work with 2.8, but I'm not sure if it cannot work with 2.9 or 3.0. Right now I'm also too short of time to test this.

Regarding PYTHON_USEDEP, would `dev-python/wxpython[opengl,${PYTHON_USEDEP}] be the right answer to this riddle?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well I suggest to add slot 2.8 if it works, but you're right the mayavi ebuils in tree do not specify a slot of wxpython either. @jlec?

Yes, specifying [opengl,${PYTHON_USEDEP}] is correct.

@junghans
Copy link
Contributor

Where is the ChangeLog?

@jamasi
Copy link
Contributor Author

jamasi commented Jan 21, 2015

/usr/portage/sci-visualization/mayavi/ChangeLog

As I only ~versionbumped the mayavi-4.3 from the main portage tree all those QA issues apply there as well.

@marbre
Copy link
Contributor

marbre commented Jan 21, 2015

Please add a ChangeLog to the science overlay too. This should contain the changes regarding the version bumped ebuild. Everthing in /usr/portage/sci-visualization/mayavi/ChangeLog isn't needed.
If you like, you can compare with sci-misc/mendeleydesktop or dev-util/nvidia-cuda-sdk. These also in the gentoo main tree, but specific versions are currently only in the overlay.

Unfortunately not every ebuild in the tree is free of QA issues. Anyway, we shouldn't push them uncleaned to the overlay. Therefore these QA issues need to be fixed.


*mayavi-4.4.0 (22 Jan 2015)

22 Jan 2015; Justin Lecher <jlec@gentoo.org> +mayavi-4.4.0.ebuild:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove @jlec from the ChangeLog and put yourself in.

@jamasi
Copy link
Contributor Author

jamasi commented Jan 21, 2015

No time for these games, CU.

@jamasi jamasi closed this Jan 21, 2015
@junghans
Copy link
Contributor

@jamasi: Could you please explain me what the problem with running repoman manifest && repoman full && repoman -m "version bump" commit is?

@junghans junghans reopened this Jan 21, 2015
@junghans junghans merged commit 3a74e60 into gentoo:master Jan 22, 2015
junghans added a commit that referenced this pull request Jan 22, 2015
@jamasi
Copy link
Contributor Author

jamasi commented Jan 22, 2015

Sorry for this loss of patience. I'm a little pressed to get mayavi back to working as a project of mine depends on it. I just thought to share the ebuild. So obviously I didn't read the current manual, but worked from memory. Now the procedure to contribute seems to have been highly formalised. A reminder to check the relevant docs right at the start of this or to simply adopt the ebuild would have been nice. Esp. as I cannot spare the time to maintain this package properly. (Also I was rather surprised that an ebuild from the main portage tree would not be of acceptable quality.)
So, sorry for causing some trouble with my attempt to contribute.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants