Simon McVittie
Assigned
Reported
Comments
"Seems Ubuntu went through the same change, but they fixed their bug somehow"
They applied a workaround so that third-party packages like Minecraft and Dropbox would be installable. This workaround is not really correct, and neither Debian nor Ubuntu will want to keep it in the long term.
It's possible that we will apply a similar workaround in Debian. However, even if we do, please don't rely on it: instead, please change Minecraft.deb so that it will install cleanly without needing the libpango1.0-0 package. This will allow the workarounds to be removed eventually.
Hi, I'm a member of the team in Debian that is responsible for packaging Pango.
I confirm that depending on libpango1.0-0 is no longer considered correct. Please make Minecraft.deb depend on the individual library packages libpango-1.0-0, etc., depending on which ones it actually needs.
Further information (originally a comment on MCL-13512):
libpango1.0-0 (without the dash) was an old Pango package containing multiple shared libraries: libpango-1.0.so.0, libpangocairo-1.0.so.0, libpangoft2-1.0.so.0, libpangox-1.0.so.0 and libpangoxft-1.0.so.0.
About 7 years ago, it was split into multiple smaller packages, one for each shared library in line with normal Debian policy (libpango-1.0-0 and so on), to make it possible to remove deprecated libraries. To make sure existing systems upgraded correctly, we also introduced a new "transitional" libpango1.0-0 package, which is empty but has dependencies on all the individual libraries that used to be included. These transitional packages are normally meant to be kept for one stable release cycle (2 years) and then removed, so we were already long overdue for removing libpango1.0-0 this year; we don't keep them forever, to avoid a large number of these transitional packages building up over time.
One of the libraries that used to be in libpango1.0-0, libpangox-1.0.so.0, is obsolete and is likely to be removed from the next versions of Debian/Ubuntu (its 32-bit version has already been removed from Ubuntu), so we can't really keep the transitional libpango1.0-0 fully intact beyond this point anyway.
The changes in version 1.44.7-2ubuntu2 of the pango1.0 source package in Ubuntu is a workaround, and is not really correct or compatible with the old libpango1.0-0: it only pulls in the main library libpango-1.0-0, and not the other related libraries.
Please change the metadata of Minecraft.deb to depend on the individual, smaller packages for each specific library that it depends on. For example, if it requires libpango-1.0.so.0 and libpangocairo-1.0.so.0, then it needs "libpango-1.0-0, libpangocairo-1.0-0" in its Depends field. These smaller packages have been available in all stable releases since Debian 8 and Ubuntu 14.04.
If you need to support even older releases (Ubuntu 12.04 and Debian 7), it is possible to have dependencies like "libpango-1.0-0 | libpango1.0-0, libpangocairo-1.0-0 | libpango1.0-0" which will accept either the new or old packages. However, these older releases have reached end-of-life and no longer receive any security support from Debian or Ubuntu, so users of these releases should really already have upgraded.
I hope this is useful information. Please let me know if you have any questions, or contact the Debian GNOME mailing list: [email protected]
Hi, I'm a member of the team in Debian that is responsible for packaging Pango.
The short answer to @violine1101 's question is: no, it is not safe to close this, and yes, this will break again with a later update of the package. Packages that depend on libpango1.0-0 are not currently installable in the development branch of Debian, which is what will become Debian 11. Even if we apply a workaround, like Ubuntu 20.04 did, we would want that workaround to be temporary (and Ubuntu will not want to keep their workaround intact in later releases either).
The longer version:
libpango1.0-0 (without the dash) was an old Pango package containing multiple shared libraries: libpango-1.0.so.0, libpangocairo-1.0.so.0, libpangoft2-1.0.so.0, libpangox-1.0.so.0 and libpangoxft-1.0.so.0.
About 7 years ago, it was split into multiple smaller packages, one for each shared library in line with normal Debian policy (libpango-1.0-0 and so on), to make it possible to remove deprecated libraries. To make sure existing systems upgraded correctly, we also introduced a new "transitional" libpango1.0-0 package, which is empty but has dependencies on all the individual libraries that used to be included. These transitional packages are normally meant to be kept for one stable release cycle (2 years) and then removed, so we were already long overdue for removing libpango1.0-0 this year; we don't keep them forever, to avoid a large number of these transitional packages building up over time.
One of the libraries that used to be in libpango1.0-0, libpangox-1.0.so.0, is obsolete and is likely to be removed from the next versions of Debian/Ubuntu (its 32-bit version has already been removed from Ubuntu), so we can't really keep the transitional libpango1.0-0 fully intact beyond this point anyway.
The changes in version 1.44.7-2ubuntu2 of the pango1.0 source package in Ubuntu is a workaround, and is not really correct or compatible with the old libpango1.0-0: it only pulls in the main library libpango-1.0-0, and not the other related libraries.
Please change the metadata of Minecraft.deb to depend on the individual, smaller packages for each specific library that it depends on. For example, if it requires libpango-1.0.so.0 and libpangocairo-1.0.so.0, then it needs "libpango-1.0-0, libpangocairo-1.0-0" in its Depends field. These smaller packages have been available in all stable releases since Debian 8 and Ubuntu 14.04.
If you need to support even older releases (Ubuntu 12.04 and Debian 7), it is possible to have dependencies like "libpango-1.0-0 | libpango1.0-0, libpangocairo-1.0-0 | libpango1.0-0" which will accept either the new or old packages. However, these older releases have reached end-of-life and no longer receive any security support from Debian or Ubuntu, so users of these releases should really already have upgraded.
I hope this is useful information. Please let me know if you have any questions, or contact the Debian GNOME mailing list: [email protected]
The 1.4.5 prerelease seems to fix this in the way I suggested (part (3) only), and works for me (with two Linux machines, both upgraded). Please try again with that version.
Seems to work correctly in the 1.4.5 prerelease (Linux LAN server, Linux client). Thanks!
As I said on #MC-2549, it looks as though my suggestion (1) from https://mojang.atlassian.net/browse/MC-473?focusedCommentId=15647&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15647 has been done, but (2) and (3) have not. At least (3) is necessary to resolve this bug.
I suggested three changes in a comment on #MC-473; it appears that (1) has been done, but (2) and (3) have not.
The two remaining changes are:
2) when announcing our address to the network, if listening on 0.0.0.0, replace it with (an attempt to find) our IP address in the 'AD' packet (optional; only needed if you want to remain compatible with versions < 1.4.4)
and more importantly
3) when parsing an 'AD' packet, ignore the IP address in the packet, and replace it with the address from which the packet was received
If Minecraft was open source (or not obfuscated) I'd have given you a complete patch 🙂 but as it is, a patch relative to the de-obfuscated source in MCP is the best I can do:
http://www.pseudorandom.co.uk/~smcv/minecraft-1.3.2-lan-server-v4.diff
(I had this working correctly as a mod for 1.3.2 / MCP 7.2; I can update it to 1.4.2 / MCP 7.19 if that would be useful, just ask.)
The change in what MCP calls LanServerList.func_77551_a is the important bit. I doubt those names match what Mojang calls that class and function internally, though.
Further explanation of the changes I suggest:
1) listen on 0.0.0.0 or :: instead of specifying a particular listening address
2) when sending AD packets to the network, if they would contain 0.0.0.0, fill in something else, to be nice to unpatched versions (getLocalHost() is a reasonable fallback)
3) when receiving an AD packet from the network, ignore the IP address appearing before the ":", and use the IP address from which the packet was received (together with the port from after the ":" as usual)
According to Zorander on the wiki, this might be a problem on Mac too:
"This is actually an issue with any OS except Windows, due to the loopback interface."
Previously reported against 1.3.2 on the Minecraft wiki. Here's my more detailed report from there:
"""
On Debian, /etc/hosts usually maps the laptop's own hostname to 127.0.1.1, an alternative loopback address (e.g. "127.0.1.1 mylaptop.mydomain mylaptop" - all of 127.0.0.0/8 is loopback).
When a Minecraft-on-Debian user advertises their single-player game to the LAN, the multicast announcement comes from their LAN IP address (e.g. 192.168.0.2), but the server only listens on 127.0.1.1 and announces that address in the multicast packet, e.g. [AD]127.0.1.1:58388/AD, making other machines unable to join.
"""
(From other people's comments here, it seems other Linuxes end up with 127.0.0.1 or 127.0.0.2.)
The cause is that InetAddress.getLocalHost().getAddress() is pretty useless on Linux: it assumes that gethostname() returns a DNS name that resolves to the an address usable by other players, which isn't generally true.
Here is a patch relative to the MCP 7.2 semi-deobfuscated source, hopefully it'll be easy enough to make the corresponding change in the real Minecraft source code:
http://www.pseudorandom.co.uk/~smcv/minecraft-1.3.2-lan-server-v4.diff
Here is permission to do what you like with that patch, including incorporating it into Minecraft: copying and distribution of the patch, with or without modification, are permitted in any medium without royalty. The patch is offered as-is, without any warranty.
"libpangox-1.0-0"
Please don't depend on this package unless Minecraft specifically needs it. It is unmaintained and obsolete, doesn't compile correctly with newer versions of Pango, and is likely to be removed from Debian and Ubuntu soon.