Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#79595 - [minetest] Potential issue with lua
Attached to Project:
Arch Linux
Opened by tuxayo (tuxayo) - Wednesday, 06 September 2023, 22:27 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:19 GMT
Opened by tuxayo (tuxayo) - Wednesday, 06 September 2023, 22:27 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:19 GMT
|
DetailsDescription:
https://github.com/minetest/minetest/issues/12778#issuecomment-1250255332 > Effects you can expect if the test fails: Minetest continues to work mostly normally, but memory leaks can happen and error handling might not work correctly in edge cases. > For this reason building with system Lua will become impossible with 5.7.0 as Minetest will ship a minimally modified version that fixes these interoperability issues (#12445). So it seems running the test can tell if Arch is affected. |
This task depends upon
Closed by Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:19 GMT
Reason for closing: Moved
Additional comments about closing: https://gitlab.archlinux.org/archlinux/p ackaging/packages/minetest/issues/2
Saturday, 25 November 2023, 20:19 GMT
Reason for closing: Moved
Additional comments about closing: https://gitlab.archlinux.org/archlinux/p ackaging/packages/minetest/issues/2
> So it seems running the test can tell if Arch is affected
And the answer is?
The upstream developer said there was a change with a dependency now being an embedded fork. Is that not appropriate to make a ticket to inform the packager of a missing dependency change? Beside, that change is to solve bugs.
>> So it seems running the test can tell if Arch is affected
> And the answer is?
When not having the project specific knowledge or time to *reliably* confirm this (and it seems not even the hardware in this case), isn't that still useful to mention it?
Or maybe the phrasing was confusing? If so, sorry for the english language mistake, I didn't mean that I was able to run the test to answer the question. It was just letting that as a lead.
That is fine. But simply latching on to some random upstream comment without proper investigation (by you) is not fine.
> not having the project specific knowledge or time
So wasting *our* time chasing potential non-bugs is ok? Honestly, the onus is on you as the bug reporter to prove there is a bug and submit an effective bug report.
I'm still confused because upstream now says "so you should always receive a working build regardless of your settings." Someone *really* needs to run the unit test.