Bug 2388961

Created attachment 2103837 [details]
sun.jpg taken from xplanet

Very simple jpg file from xplanet

Looks like https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/merge_requests/219 but it's not in a release yet.

Proposed as a Blocker and Freeze Exception for 43-final by Fedora user augenauf using the blocker tracking app because:

 Default application functionality

Out of the list of blocking applications:

    web browser
    file manager
    package manager
    image viewer
    document viewer
    text editor
    archive manager
    terminal emulator
    problem reporter
    help viewer
    system settings

which of them have "basic functionality" broken by this bug?

Saving jpeg works. But jpeg has no support for transparency, so saving pixbufs with alpha to jpeg fails.

The commit you refer to has been in releases for a while

Hello. This is a bulk comment.

This package still needs to be rebuilt and/or shipped with Python 3.14.0rc3+ bytecode in Fedora 43.

The Final Freeze of Fedora 43 is scheduled to start next week. Please prioritize this bugzilla accordingly.

Thanks.

-6 in https://pagure.io/fedora-qa/blocker-review/issue/1949 , marking rejected blocker. FE vote still open.

> Saving jpeg works. But jpeg has no support for transparency, so saving pixbufs with alpha to jpeg fails.

Then...how do we get a pixbuf with transparency by *loading* a JPEG?

You could if it started out as JPEG XL. It's a superset of JPEG but is expected to be parseable by classic JPEG codecs.

AGREED Delayed decision (punt)

Discussed at the 2025-09-29 (blocker / freeze exception) review meeting:

We felt like this could potentially be something with enough of an impact to justify a FreezeException, but nobody has yet demonstrated such impact. We agreed to punt to give folks a chance to demonstrate a problem in a typical pre-install/pre-update use case.

https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2025-09-29/f43-blocker-review.2025-09-29-16.03.txt

Relevant discussion in this upstream issue: https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/268

Please retry with gdk-pixbuf 2.44.3. We can't reproduce the problem with current glycin and gdk-pixbuf versions.

AGREED RejectedFinalFreezeException

Discussed at the 2025-10-06 (blocker / freeze exception) review meeting:

There's still been no clear rationale for why this bug as described would justify a freeze exception. We will reconsider this decision if any such justification appears.

https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2025-10-06/f43-blocker-review.2025-10-06-16.00.txt

Note that my "original" report is (was( that (as you can see on https://bugzilla.redhat.com/show_bug.cgi?id=2388961#c0 )

Even loading jpeg file, then saving it "as it is" fails (failed).

So (In reply to Matthias Clasen from comment #5)
> Saving jpeg works. But jpeg has no support for transparency, so saving
> pixbufs with alpha to jpeg fails.

Again:
the original bug was, as jpeg has no support for transparency, 
after loading jpeg, pixbuf should say "no alpha", but 
(as I said in the first comment) even after loading jpeg, pixbuf says (said)

> Note that "has_alpha" says 1 (even if the input file is jpeg)

and this is (was) also wrong (as gdk-pixbuf2-2.42.12 said, generated pixbuf should say "no alpha"), 
and saving the pixbuf to jpeg was not working.

So this summary changing:
> Summary: glycin backend saving jpg format does not work at all → glycin backend saving jpg format with alpha channel does not work at all
is really not what I reported.

Then: the original bug I reported seems to be already fixed. Not sure if glycin backend saving jpg format "with alpha" channel works now.

*** Bug 2403337 has been marked as a duplicate of this bug. ***