Package: pngtools Version: 1.2-1 Severity: wishlist Continuing bugs.debian.org/1123747, when the pHYs chunk is absent, pngtool reports “Resolution: (not specified)”. This is pointless. Except textual chunks, the tradition has been not to mention an ancillary chunk at all if it's absent. Indeed, there are many other chunk types, the absence of the instances of which is not reported. Example with pHYs and sBIT: $ grep pHYs /usr/share/inkscape/screens/start-support-time.png /usr/share/inkscape/themes/Minwaita-Inkscape/gtk-3.0/assets/bullet-symbolic.symbolic.png grep: /usr/share/inkscape/screens/start-support-time.png: binary file matches $ grep sBIT /usr/share/inkscape/screens/start-support-time.png /usr/share/inkscape/themes/Minwaita-Inkscape/gtk-3.0/assets/bullet-symbolic.symbolic.png grep: /usr/share/inkscape/themes/Minwaita-Inkscape/gtk-3.0/assets/bullet-symbolic.symbolic.png: binary file matches $ pnginfo /usr/share/inkscape/screens/start-support-time.png /usr/share/inkscape/themes/Minwaita-Inkscape/gtk-3.0/assets/bullet-symbolic.symbolic.png | egrep -i "/usr|bit|resolution" /usr/share/inkscape/screens/start-support-time.png... Bitdepth (Bits/Sample): 8 Resolution: 3779, 3779 (pixels per meter) /usr/share/inkscape/themes/Minwaita-Inkscape/gtk-3.0/assets/bullet-symbolic.symbolic.png... Bitdepth (Bits/Sample): 8 Resolution: (not specified) Here, the absence of sBIT was not reported, but the absence of resolution was. Suggestion: if the pHYs chunk is absent, drop the line “Resolution: (not specified)”, as it is just additional clutter versus the plain absence of “Resolution: …”.
severity 1132795 normal thanks I concur with the request. Indeed, “Resolution: (not specified)” sounds as if the tag were present in the file, but no value for the tag were supplied. This is not the case for the tested files: they have no pHYs at all. Thus, raising the severity.
在 2026/5/28 04:52, Md Ayquassar 写道:
I looked into his other comments on the closed bug reports, and they were on topic. Any idea what to do if the upstream maintainer is clearly not that well? Am 28.05.26 um 03:59 schrieb xiao sheng wen(肖盛文):
Hi, 在 2026/6/2 15:07, Emma Müller 写道: Upstream first, do nice communicate to upstream author is better. Certainly, we are all volunteer in open source project, upstream author sometimes perhaps wouldn't fix some bugs. Debian bugreport is public, perhaps some people would contribute a patch. Wishes!
My this first reply email is lost, I use my Debian email forward it again. -------- 转发的消息 -------- 主题: Re: Bug#1132795: Drop “Resolution: (not specified)” if no pHYs 日期: Wed, 3 Jun 2026 09:36:26 +0800 发件人: xiao sheng wen(肖盛文) <atzlinux@sina.com> 回复地址: 1132795@bugs.debian.org 组织: https://www.atzlinux.com 收件人: Emma Müller <emma2@ro.ru>, 1132795@bugs.debian.org Control: tags -1 upstream Hi, You reply my email to my personally email address only, please CC to 1132795@bugs.debian.org too. Debian bugreport is public: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1132795 every one can read and reply it. 在 2026/6/3 06:45, Emma Müller 写道: The libpng-tools package has one command pngfix can do some png fix. https://libpng.org/pub/png/libpng.html pngchunks /usr/share/inkscape/themes/Minwaita-Inkscape/gtk-3.0/assets/bullet-symbolic.symbolic.png This can get more detail info about png chunks. I said the word "some people" who include the open source developer, not only normal end user. The package pngtools is team maintainer by Debian photo team: Debian PhotoTools Maintainers <pkg-phototools-devel@lists.alioth.debian.org> https://qa.debian.org/developer.php?login=pkg-phototools-devel@lists.alioth.debian.org The Debian bugreport of any package maintainer by Debian photo team also CC to this mailing lists. Our team member will receive this bugreport. https://salsa.debian.org/groups/debian-phototools-team/-/group_members The issue on the upstream github, also is public. https://github.com/mikalstill/pngtools/issues/37 If there one "open source developer" find these information and also has interest to fix this bug, they will do it. Good lucky!
Oh hello, how nice of you all to be concerned for my mental health. Fortunately, I am relatively content with my general state of mind. I do however have some thoughts on this bug: * Six words and a link is not a valid upstream bug report. Its super lovely that you're over here chatting about me, but you really do need to provide a meaningful report upstream if you expect a donation of my time to make a change you desire. This is especially true given this code isn't a focus of my attention and hasn't been for most of this century. * Perhaps you could "sell" your request a bit better as well? "pointless" and "Any idea what to do if the upstream maintainer is clearly not that well" are perhaps not a great way to get me to do a thing for you? * Additionally, I also don't think you've demonstrated that this is in fact a bug, either on the debian bug tracker or the upstream bug tracker. Why do you think its erroneous? The resolution of the image is in fact not specified. Certainly I think the previous behaviour was worse [1], and given I am the one who gets to merge things surely that counts for something? Additionally, its super weird that you'd assume the use of a modern coding assistant implies some sort of professional incompetence on my part, especially when the commit as linked above is pretty clear cut. * The output is also trivial to work around if you don't like it. Just grep it away or whatever in whatever script you're wrapping pnginfo in. I will consider a pull request on its merits when one is uploaded to github. Michael 1: https://github.com/mikalstill/pngtools/commit/b765d38baef047c7edd335aa9187f5b4278cecaa
Dear xiao sheng wen, dear Debian PhotoTools Maintainers, I originally didn't want to call the author cognitively dishevelled, but him dismissing the Debian bug report as babble on a “random other site” and then lecturing us on upstream interaction is just charming. “Six words and a link is not a valid upstream bug report... you really do need to provide a meaningful report upstream” is so much a strong argument; it proves the author's ability to click and a willful, sooo good-faith move. “given I am the one who gets to merge things surely that counts for something?” and “I await someone making a convincing argument" prove convincing, final, unchallengeable, and unassailable authority. “its super weird that you'd assume the use of a modern coding assistant implies some sort of professional incompetence on my part” elegantly transforms a missing chunk into missing respect – super logical! “The output is also trivial to work around if you don't like it. Just grep it away” is equivalent to defending a splinter in a chair by saying, “Just sit a bit to the right; it's easy.” Reformulating my #10, the phrasing “Resolution: (not specified)” is misleading: the absence of pHYs does not say there is a “not specified” value but means complete nonexistence including the tag name. Printing the line creates a bogus similarity with tags without data, tricking the reader into a belief that pHYs could contain nothing. Better, non‑arbitrary: consistency with the prior behavior (omission for absent chunks such as sBIT). The phrasing “Resolution: (not specified)” is noisy, regardless of whether we look at the output, parse it, or diff it. Once the reads gets the pHYs semantics, the phrase serves no purpose. The “deliberate change” (my suspicion is that it has been sooo much looked at) trades clarity for verbosity – alas, without more insight. The claim that one can “just grep it away” is absurd. Requiring a user to post‑process the output of a tool that claims to inspect PNG files is an admission that the tool's printout is broken by design. In summary, removing the line when the PNG contains no pHYs would improve correctness and usability. I would be thankful to the Debian maintainers if I could kindly ask them to fix this regardless of the upstream author's, erm, hermeneutically challenged posture. Gratefully, Md
Once the reads gets … -> Once the reader understands …
Hi, 在 2026/6/10 06:23, Md Ayquassar 写道: If pHYs chunks not exist in the png file, not printout any info about "pHYs chunks" is also ok. I'll try add a patch to do so and release a Debian revised release. Requiring a user to post‑process the output of a tool, that should been acceptable. Nothing is perfect complete, especially in the opensource world. Regards,
We believe that the bug you reported is fixed in the latest version of pngtools, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1132795@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. xiao sheng wen <atzlinux@debian.org> (supplier of updated pngtools package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org) Format: 1.8 Date: Wed, 10 Jun 2026 11:39:31 +0800 Source: pngtools Architecture: source Version: 1.2-2 Distribution: unstable Urgency: medium Maintainer: Debian PhotoTools Maintainers <pkg-phototools-devel@lists.alioth.debian.org> Changed-By: xiao sheng wen <atzlinux@debian.org> Closes: 1132795 Changes: pngtools (1.2-2) unstable; urgency=medium . * Team upload. * d/copyright: delete outdated URL * add d/p/pnginfo.c-#1132795.patch, Closes: #1132795 * Bump to Standards-Version: 4.7.4 * d/control: remove Priority: optional line * d/watch: converted to version 5 Checksums-Sha1: 40c1faeaaa11c04ab22a529a5ca9df4d63828e96 1974 pngtools_1.2-2.dsc 2bc5177ca618f0022dce009652d6564bf45da40a 3568 pngtools_1.2-2.debian.tar.xz 01e9184dfa2f7f43d39d2737c1b7d281839fd366 8469 pngtools_1.2-2_source.buildinfo Checksums-Sha256: 573fab79803d850e4189b83a46fe7d5dce3711f21c08a1af7be04a191a0cdb90 1974 pngtools_1.2-2.dsc ea2ea46537e5ecb5cbdcbbfabda21f60ef5fef373f3666270310b8c2a58f205b 3568 pngtools_1.2-2.debian.tar.xz 748c7157465b9247fc3e5679415e5b77d7b28c7a4dd89fa6d84456da5cc49993 8469 pngtools_1.2-2_source.buildinfo Files: 5e0d3037b787d54326278f19efaadc81 1974 graphics optional pngtools_1.2-2.dsc 404b475799ed884f611be26ea1174020 3568 graphics optional pngtools_1.2-2.debian.tar.xz 497e1e2e04fda7b80eebdb9b454a583a 8469 graphics optional pngtools_1.2-2_source.buildinfo -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvGv7H5NUQYeSuhtTJ2Egg8PSprAFAmoo5GQACgkQJ2Egg8PS prBZ0xAAhfUaPnd+BCMWfzkDFflW9BOjWAxE8EspymfmJ3UBuDCYFN6HWWLdyzbH q0qXt7Kn5lPUGaNDkw3h0I7cPiqu5Z7NzPiohZXE8JOEuERSzmOHIAUyY6Kesgs3 dogPEksi+wMmvQYyrbtBu02CUHCoJO8G4dnHa3lP93TdUn76dXZbo3YrGh+Q4CRy qVrnREWqZXbvq5pVLAHDXNTCc0OCZuAZb3Eq2KpxTsQR52kU4v8Ny7bkubC0rTrz NIbZ8XIO7r8LPAvuddb1dHij58sizSs8qmSpWewIZgFwEajkgjKfGflQ+BGWDNYV yjtj8Ro3XbHXsrz7ObzSt+DNDYCXTm2NnnJWSyBxcOBZb+/41mchVi+udyg74oan UPQ7O1W4jaN7+mBJ5nFkpt9coqmoEbKLnJfvWj+ABthwG9iiIvfpEo98IcVB2RRE eT0U63XGp4IyLhPpizkKwVrJRPPZ3NMZI2e/5hPeKDXEiecwxWvYIlAyTQ4e6Qnf 2UOOReN0CCreY3gf93VA+7oovyCPpHL84tSogGPgqCABMygKvNFs/ruXtiPQ29JP RMTL7CNFhCBnj/av1MZY2kd80mfTCuTBmB/OZTj/icwSxRknJGkMw9AXIc/bmBfu 65QpxYPcEJG9ErmDohDy2wWxQT7+KIUK/LWcdhTP4vQq5nzF9hI= =zu04 -----END PGP SIGNATURE-----
Hi xiao! I downloaded the upgraded package. It works like a charm. Thank you very much for the fix!!! Sincerely, Emma
Hi xiao sheng wen, I do partly understand why the upstream developer is reacting that way. I think that atzlinux¹ way of forwarding the bug upstream comes along a bit unfriendly. We, as Debian, want something from upstream, so we need to be friendly. When I forward a bug upstream, I paraphrase the issue, give all information that upstream needs to act on THEIR bugtracker, and at the end write something along the line "see also the original Bug report on the Debian BTS on http://bugs.debian.org/<number>". Make it easy for upstream to fix things. Be polite. That helps a lot. Greetings Marc ¹ I assume that you are also atzlinux on Github. If that's not the case, please accept my apology.
Hi, Thanks your email. 在 2026/6/17 18:54, Marc Haber 写道: Yes, you're right! I'm sorry for my English level. For word "is pointless", after this case, I realized it's not friendly. The orig bug reporter perhaps is come from Russian, I guess this from his email, so he is also not the English mother language speaker. From technical view, I readed the bug report carefully and test and verify it in my local machine before I forward this bug to upstream, so I don't more thing for paraphrase the issue. If fact, this bug is not very complex to understand. If I almost just copy and paste the Debian bug report to upstream github issue, it's not necessary sometimes. Yes, it's me. Greetings,