Bug 285185
| Summary: | graphics/gdk-pixbuf2: some programs fail without extra loaders | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | rkoberman | ||||
| Component: | Individual Port(s) | Assignee: | freebsd-desktop (Team) <desktop> | ||||
| Status: | Open --- | ||||||
| Severity: | Affects Many People | CC: | andy, bsd, bugzilla.freebsd, christopherhall.hsw, crahman, freebsd.68fba, jcfyecrayz, lumiwa, pere_goriot99, shurd, tom+fbsdbugzilla, vishwin, vvd, zirias | ||||
| Priority: | --- | Flags: | vishwin:
maintainer-feedback+
|
||||
| Version: | Latest | ||||||
| Hardware: | amd64 | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
|
Description
rkoberman
2025-03-05 20:36:50 UTC
After rolling graphics/gdk-pixbuf2 to 2.42.10_3, gkrellm is working correctly agai, so there is no questionof the source of the problem. After looking at the update, I see that several older image formats (xpm, ani, bmp, icns, ico, pnm, qtif, tga, and xpm) were placed into a non-default 'OTHERS' build option. As a result, any software using these formats will no longer function. There was no indication of this change; just updating packages that used any of the OTHER formats stopped working. This is a significant POLA violation. At very least, I think that an UPDATING entry would be appropriate. This is worse than that - I experienced exactly the same problem with mail/clawsmail, and basically every xpm consumer could be affected. And downgrading gdkpixbuf2 solved the issue for me as well. Don't know if this helps, but the commit that changed the build options in the upstream project is https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/commit/e052a112075a19fb75f1f2ff3de4c82923de13f2 As many ports make use of "OTHER" image formats, it makes it impossible to use them for those using packages. The options I see are: 1 Make "OTHER" a default 2. Flavorize the port with an OTHER flavor 3. Create a gdk-pixbuf2-other port. Name might be clearer as gdk-pixbuf2-all-formats) Rebuilding the gdk-pixbuf2 port with OTHERS build option added makes the problem disappear for me. As I am building everything from sources, it was just unexpected change came in unnoticed. (In reply to bsd from comment #3) I have claws-mail problem too and Geequie doesn't show bmp. A week ago I clean pkg cache. Until something is done to the port, the only solution is to build the port from sources and configure selecting OTHER. This also affects builds, for example games/eduke32: --- gdk-pixbuf-csource --extern --struct --raw --name=startbanner_pixdata source/duke3d/rsrc/game.bmp | sed 's/load_inc//' >> obj/duke3d/game_banner.c failed to load "source/duke3d/rsrc/game.bmp": Couldn’t recognize the image file format for file “source/duke3d/rsrc/game.bmp” [...] ld.lld: error: undefined symbol: startbanner_pixdata >>> referenced by startgtk.editor.cpp >>> obj/build/mapster32.lto.startgtk.editor.o:(startwin_open) clang++: error: linker command failed with exit code 1 (use -v to see invocation) gmake: *** [GNUmakefile:803: mapster32] Error 1 --- Upstream discussion for reference: https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/merge_requests/169 This seems to indicate those formats won't come back any time soon in the default build. Therefore a flavor might be the way to go, so explicit dependencies can be used in dependent ports. Adding vishwin@ as the last committer, any thoughts here? I don't intend on flavourising this. With the current gdk-pixbuf code, can't really build the other loaders separately/isolated without a lot more complexity in both code and port. Flavourising adds more complexity to the ports framework without much benefit since this has many consumers. Also not exactly keen on re-enabling OTHER by default; upstream has been firm about discouraging use of effectively unmaintained code. However, one of the upstream maintainers split these loaders into a separate repository with a build system to match. I'm open to porting that and removing the OTHER option. (In reply to rkoberman from comment #2) Was the commit message, both with the changelog link and the explicit separate notable mention of this, not enough? wrt POLA in general, sometimes upstreams have to make decisions to keep their projects moving. What can seem like a sudden astonishing change may have been brewing for some time but consumers were not paying attention (for a variety of reasons, like debt) until the full impact happened. In this specific case, they admitted that doing this in the existing release branch was poorly executed, but it had to be done. (In reply to Felix Palmen from comment #9) Upstream wants to divest these loaders entirely from the main codebase. (In reply to Charlie Li from comment #11) > Upstream wants to divest these loaders entirely from the main codebase. I see, nevertheless right now, it breaks stuff in our tree. So maybe the least bad would be to enable OTHER by default for now to allow for the transition to hopefully happen ... Something should be in /usr/ports/UPDATING and will be less problem. I didn't know that I expected a mess. Created attachment 258577 [details]
new port v0
Rough once-over of a new port with those divested loaders, give it a try.
Comment on attachment 258577 [details]
new port v0
forgot to mention, port name is in anticipation to renaming everything gdk-pixbuf without the "2"
*** Bug 285343 has been marked as a duplicate of this bug. *** (In reply to Charlie Li from comment #11) In general, I agree with most of your views. I think FLAVORS is generally overkill as other options with FAR less overhead are available. None the less, this change had some real issues that were not addressed by the commit. The most serious one was that the change broke any ports with no warning. Mot people, myself included, update ports without looking at commit messages and, even then, there was no information of what formats had been removed from the default build to let people know what would be broken. In my case, I have multiple instances of a broken application running continually that showed no problems as the change only took effect when I rebooted my system. I did a quick check of UPDATING and found nothing. Definite astonishment for me. I'll agree that it took minimal effort to look at the commit, realize that I needed to enable OTHER, and get my system monitors back in operation. An obvious place to get people's attention would be to add a pkg-message to warn people that the following formats (list of them) would require a build with OTHER enabled. This is a much bigger issue for system updated with packages. Those not building from source have no easy fix. Maintaining a mix of ports and packages can be very difficult and trigger rather obscure problems that are not easy to track down. Maintaining a system which mixes ports with packages is a major pain, not really acceptable. Repeatedly there have been posts from major committers that this was a very bad idea (often from Bapt) and that it should be avoided if at all possible. I have one such port, emacs, that is a real pain to update as I have to resolve all dependency conflicts every time that it is updated on systems that I maintain with packages. *** Bug 285354 has been marked as a duplicate of this bug. *** Bug 285389 is another one related to this... *** Bug 285389 has been marked as a duplicate of this bug. *** A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=e129c081e39271edac0d7b8aa174930f4317a796 commit e129c081e39271edac0d7b8aa174930f4317a796 Author: Charlie Li <vishwin@FreeBSD.org> AuthorDate: 2025-03-11 21:38:21 +0000 Commit: Charlie Li <vishwin@FreeBSD.org> CommitDate: 2025-03-17 04:04:29 +0000 graphics/gdk-pixbuf-extra: add default-disabled loaders With the new port, remove OTHERS from graphics/gdk-pixbuf2, and add corresponding helper to USES=gnome. Ports using the affected loaders should declare USE_GNOME=gdkpixbufextra. PR: 285185 Mk/Uses/gnome.mk | 6 +++++- UPDATING | 12 ++++++++++++ graphics/Makefile | 1 + graphics/gdk-pixbuf-extra/Makefile (new) | 22 ++++++++++++++++++++++ graphics/gdk-pixbuf-extra/distinfo (new) | 3 +++ graphics/gdk-pixbuf-extra/pkg-descr (new) | 12 ++++++++++++ graphics/gdk-pixbuf-extra/pkg-plist (new) | 10 ++++++++++ graphics/gdk-pixbuf2/Makefile | 7 ++----- graphics/gdk-pixbuf2/pkg-message (new) | 12 ++++++++++++ graphics/gdk-pixbuf2/pkg-plist | 9 --------- 10 files changed, 79 insertions(+), 15 deletions(-) Keeping this open to track any ports that need USE_GNOME=gdkpixbufextra declared. *** Bug 285430 has been marked as a duplicate of this bug. *** A problem with this approach is that it will result in a situation where ports which have not been marked with gdkpixbufextra but which need one of the extra loaders will compile and be packaged successfully, but will only work when another port which has gdkpixbufextra have been installed. At the very least, this change should be held back until all the possible ports have been studied for the use of xpm's or other 'extra' loader usage. Perhaps it would be best to simply make gdk-pixbuf2 depend upon the gdk-pixbuf-extra port through an option that defaults to 'true'. Meanwhile, wmdrawer has been broken. It needs the xpm loader, but it now works on my system since I have installed the -extra loaders through gkrellm2. However, the option gdkpixbuf2xlib has been renamed gdkpixbufxlib in the wmdrawer port Makefile, but the Mk/Uses option has not been renamed, and so it fails to build. A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=0a5479b86b57ac3bf092233ac587cc76f9b2c77a commit 0a5479b86b57ac3bf092233ac587cc76f9b2c77a Author: Guido Falsi <madpilot@FreeBSD.org> AuthorDate: 2025-03-18 10:31:46 +0000 Commit: Guido Falsi <madpilot@FreeBSD.org> CommitDate: 2025-03-18 10:34:58 +0000 x11/libxfce4menu: Depend on gdkpixbufextra XFCE uses XPM images and other "uncommon" formats, force a dependency on gdkpixbufextra to ensure it is installed at runtime whenever any XFCE component is installed to avoid graphic glitches. PR: 285185, 285430 x11/libxfce4menu/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) *** Bug 285498 has been marked as a duplicate of this bug. *** *** Bug 285518 has been marked as a duplicate of this bug. *** I'm worried about future sabotage of gtk2 like this |
