Summary: | games-board/pysolfc-2.1.2 version bump | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | neil |
Component: | Current packages | Assignee: | Gentoo Games <games> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | jstein, radu.baetica |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
pysolfc-2.1.2.ebuild (bad)
PysolFC-2.2.0 ebuild errors |
Description
neil
2018-02-03 21:30:16 UTC
Since I don't really know what I'm doing, it would probably make more sense for someone who knows what they're doing to version-bump this themselves, completely ignoring my attachment. But, I included it for the sake of completeness. Thank you for your contribution. I had a short look on the ebuild. Here a few ideas: * Please test the ebuild with repoman full -x https://wiki.gentoo.org/wiki/Repoman * please fix the header. (see /usr/portage/skel.ebuild and https://devmanual.gentoo.org/ebuild-writing/eapi/) # Copyright 1999-2016 Gentoo Foundation # Copyright 1999-2018 Gentoo Foundation * Do you need eutils? * doesn't the package need one of the helpers to update the menu and icons? https://wiki.gentoo.org/wiki/Notes_on_ebuilds_with_GUI * I would avoid the definition of a variable SOL_URI="mirror://sourceforge/${PN}" but write it in the SRC_URI line. It makes the ebuild more difficult to read brings no improvements. I'm already aware that the ebuild is severely defective, as it was a hackish edit I did of pysolfc-2.0-r5.ebuild without understanding much about ebuilds. I'm not even sure why I contributed it; I guess it just seemed better to attach *something* rather than just complaining that the thing needed updating. Although, that weird SOL_URI variable was present in the original. Not terribly comforting to know that this ebuild was already non-standard even *before* I started messing with it... If I use `repoman full -x`, will that give more info than `repoman --digest=y -d full`? Because that's what I used, and it actually didn't complain at all despite how faulty this ebuild is. Okay, I ran `repoman full -x`, and this happened: --------- RepoMan scours the neighborhood... Note: use --include-dev (-d) to check dependencies for 'dev' profiles RepoMan sez: "If everyone were like you, I'd be out of business!" --------- So, as far as the automated checker is concerned, there isn't apparently anything wrong. Of course that's not saying it doesn't need repair, only that the problems are all outside the scope of Repoman's tests. I wish to add my own failure at compiling PysolFC-2.2.0 (which is my favorite game by far) It fails at compile phase with: running build_scripts creating /var/tmp/portage/games-board/pysolfc-2.2.0/work/PySolFC-pysolfc-2.2.0-python3_6/scripts copying and adjusting pysol.py -> /var/tmp/portage/games-board/pysolfc-2.2.0/work/PySolFC-pysolfc-2.2.0-python3_6/scripts changing mode of /var/tmp/portage/games-board/pysolfc-2.2.0/work/PySolFC-pysolfc-2.2.0-python3_6/scripts/pysol.py from 644 to 755 * python3_6: running distutils-r1_run_phase python_compile_all Traceback (most recent call last): File "gen-html.py", line 6, in <module> from pysollib.mygettext import fix_gettext ModuleNotFoundError: No module named 'pysollib' And I attached in pysolfc220errors.tar.bz: emerge --info '=games-board/pysolfc-2.2.0::gentoo > emerge__info emerge -pqv '=games-board/pysolfc-2.2.0::gentoo > emerge__pqv /var/tmp/portage/games-board/pysolfc-2.2.0/temp/build.log /var/tmp/portage/games-board/pysolfc-2.2.0/temp/environment as advised by the ebuild error. How else may I help? Created attachment 532342 [details]
PysolFC-2.2.0 ebuild errors
Thanks for the work here, closing this bug as 2.2.0 was added in tree in May |