Minetest 0.4.11 was released on Dec 26, 2014. https://github.com/minetest/minetest/releases/tag/0.4.11 Minetest_game-0.4.11 was released on Dec 21, 2014 https://github.com/minetest/minetest_game/releases/tag/0.4.11
(In reply to Jaak Ristioja from comment #0) > Minetest 0.4.11 was released on Dec 26, 2014. > > https://github.com/minetest/minetest/releases/tag/0.4.11 > > Minetest_game-0.4.11 was released on Dec 21, 2014 > > https://github.com/minetest/minetest_game/releases/tag/0.4.11 Thank you for the reminder, i am currently working on the ebuilds for version 0.4.11. The ebuilds are so far ready and i tested them succesfully on my machine, i am right now just waiting for review of my ebuilds from the proxy-maintainer team and the following submission to the portage tree by them.
Created attachment 394112 [details] minetest-0.4.11.ebuild
Created attachment 394114 [details] minetest_game-0.4.11.ebuild
(In reply to Julian Ospald (hasufell) from comment #3) > Created attachment 394114 [details] > minetest_game-0.4.11.ebuild I tested both ebuilds in my local overlay, the one for minetest_game seems fine so far but i have a question related to the other ebuild. Shouldnt the patches that get applied at lines 58 and 59 be renamed to the appropriate version number so that ${FILESDIR}"/${PN}-0.4.10-shared-irrlicht.patch -> ${FILESDIR}"/${PN}-0.4.11-shared-irrlicht.patch and ${FILESDIR}"/${PN}-0.4.10-as-needed.patch -> ${FILESDIR}"/${PN}-0.4.11-as-needed.patch ? I mean we have the patches for version 0.4.9 and the patches for 0.4.10, so having the patches for 0.4.11 would be just consistent.
https://github.com/hasufell/gentoo-portage/commit/c73f368688c1938fd5e0b261d4da902cf25ae661 https://github.com/hasufell/gentoo-portage/commit/b7db016c4f23f2a2c1d3292e65d68d2a70146652
(In reply to Julian Ospald (hasufell) from comment #5) > https://github.com/hasufell/gentoo-portage/commit/ > c73f368688c1938fd5e0b261d4da902cf25ae661 > https://github.com/hasufell/gentoo-portage/commit/ > b7db016c4f23f2a2c1d3292e65d68d2a70146652 Everything is okay from my side then.
https://github.com/hasufell/gentoo-portage/compare/hasufell:a6c138e31dfd88336dcec9f42deb9bcbef8f0adf...master.patch
Created attachment 397388 [details] ebuild for minetest-0.4.11 including the fix for bug #541122
Created attachment 397390 [details, diff] Required patch for 0.4.11
Created attachment 397392 [details, diff] Another reuqired patch for 0.4.11
(In reply to Martin-Kevin Neumann from comment #8) > Created attachment 397388 [details] > ebuild for minetest-0.4.11 including the fix for bug #541122 Attachment #394112 [details] is obsolet now. Attachment #394114 [details], #397388, #397390, #397392 are all the required files to bump minetest to 0.4.11
0.4.12 is out a long time ago, please make a ebuild for it instead of 0.4.11
(In reply to neko259 from comment #12) > 0.4.12 is out a long time ago, please make a ebuild for it instead of 0.4.11 I will look into it, but i am just wondering why it takes so long to bump that package, the work was already done it just needed someone to look at the provided files and check if everything is alright and then commit it to cvs. If there are issues with the files, why do i get no feedback at all about it?
(In reply to Martin-Kevin Neumann from comment #13) > (In reply to neko259 from comment #12) > > 0.4.12 is out a long time ago, please make a ebuild for it instead of 0.4.11 > > I will look into it, but i am just wondering why it takes so long to bump > that package, the work was already done it just needed someone to look at > the provided files and check if everything is alright and then commit it to > cvs. > > If there are issues with the files, why do i get no feedback at all about it? I don't know if there's a good answer to that. I'll look tomorrow to committing what's here, late here. Work on the bump
In the latest version of your ebuild, you have enewuser ${PN} -1 -1 /var/lib/${PN} ${PN} In the previous version, it was enewuser ${PN} -1 -1 /var/lib/${PN} ${GAMES_GROUP} Two comments, 1) as is, the group ${PN} doesn't exist so this fails. You'll need to create it, or, see the next comment. 2) Generally speaking, games should use the ${GAMES_GROUP}. You might want to get an opinion from someone more intimately involved with the games herd, but I think you probably keep to the GAMES_GROUP unless you really need your own group for another reason.
MN 1. It took me a long time to decipher Comment 11, mainly due to simply syntax and style. The reading of all this info would be made easier by having given these a name at the time of attachment. (Don't have us guessing) 2. When I did, I found that they were in fact duplicates of files/{minetest-0.4.10-as-needed.patch,minetest-0.4.10-shared-irrlicht.patch}. We do NOT care to fill FILESDIR with duplicates of the same patch; "${FILESDIR}"/${PN}-0.4.10-shared-irrlicht.patch \ "${FILESDIR}"/${PN}-0.4.10-as-needed.patch relieves us of this. 3. While a whole ebuild is perfectly fine, it's preferred to make a diff -u patch of a bumped ebuild and the prior version. In this case the adjustment in 2. is trivial, it can be simply edited after the patch is used to edit a copy paste of the prior ebuild. diff -u minetest-0.4.10-r2.ebuild minetest-0.4.11.ebuild > /path/to/somewhere/nice/minetest.patch attach patch and then we can /correct/path/patch < /path/from/somewhere/nice/minetest.patch minetest_game-0.4.11.ebuild is as yet untested. NP-Hardass has installed all deps and the ebuild completes to install once the group was edited to ${PN}. Still, good work. Keep it up.
rather, once the group was edited to ${GAMES_GROUP}.
(In reply to Ian Delaney from comment #16) > > We do NOT care to fill FILESDIR with duplicates of the same patch; > That is up to the maintainer.
It's also poor form and a waste of space
Created attachment 398614 [details, diff] New patch for the version bump I cleaned up the ebuild for 0.4.11 and created a patch of it now. Thanks for the feedback so far. Having the same patches for different versions wasnt my idea, i just followed the pattern for the beginning. I am thinking about changing that but i'll need some more time to make that decision so for now i want stay with having multiple patches.
(In reply to Ian Delaney from comment #19) > It's also poor form and a waste of space your opinion on this doesn't matter when the games herd explicitly asked the maintainer to do it that way
Created attachment 399638 [details, diff] 0.4.12 bump and changes applies to 0.4.10-r2
Sorry for the double message... The patch I just attached: includes the doc patch from this bug uses files/0.4.10* patches instead of creating new ones for 0.4.12 remove "rm -r src/sqlite || die" from ebuild as it no longer exists in 0.4.12 source Builds with and without doc on x86-64; minor testing -- loaded world and saw it come up Builds with crossdev for armv7 - no testing minetest_game just needs a version bump
(In reply to myoung008 from comment #23) > Sorry for the double message... > > The patch I just attached: > includes the doc patch from this bug > uses files/0.4.10* patches instead of creating new ones for 0.4.12 > remove "rm -r src/sqlite || die" from ebuild as it no longer exists in > 0.4.12 source > > Builds with and without doc on x86-64; minor testing -- loaded world and saw > it come up > > Builds with crossdev for armv7 - no testing > > minetest_game just needs a version bump Just tested the ebuild on both an AMD64 and an Intel Pentium M 1.73GHz i686-32 Everything seems fine, clean compile... :)
(In reply to Julian Ospald (hasufell) from comment #21) > (In reply to Ian Delaney from comment #19) > > It's also poor form and a waste of space > > your opinion on this doesn't matter when the games herd explicitly asked the > maintainer to do it that way Then I do not wish to play this game and support such an approach. A case here for the games authors or someone else in the proxy herd to see this committed.
(In reply to Ian Delaney from comment #25) > (In reply to Julian Ospald (hasufell) from comment #21) > > (In reply to Ian Delaney from comment #19) > > > It's also poor form and a waste of space > > > > your opinion on this doesn't matter when the games herd explicitly asked the > > maintainer to do it that way > > Then I do not wish to play this game and support such an approach. A case > here for the games authors or someone else in the proxy herd to see this > committed. It's called respect for the herd/project involved in maintenance... following their style recommendations. Would you like people to ignore python project policies?
https://bugs.gentoo.org/show_bug.cgi?id=558978 As you can see, work started on bumping to 0.4.13 so i close the bug as 0.4.11 will be skipped.