Adds a use flag to enable building qrencode without png support. Reproducible: Always
Created attachment 764867 [details] qrencode ebuild with png use flag
Why is building qrencode without png support a useful thing to do?
Comment on attachment 764867 [details] qrencode ebuild with png use flag Please don't attach full ebuild and check out the copyright policy.
(In reply to Matt Turner from comment #2) > Why is building qrencode without png support a useful thing to do? Because the author of qrencode supports building it in that way via a configure flag "--with{out}-png". Because qrencode can display qr codes directly on the console, which is useful in scenarios where there is not a display manager. In my specific use case, I have a very small image that I boot over PXE (Linux kernel, plus probably not more than 5mb). The devices that boot this image roll by on a conveyor, and operators may scan the qr code from the screen. qrencode is invoked with the "-t utf8" option in order to use it in this fashion.
(In reply to Michał Górny from comment #3) > Comment on attachment 764867 [details] > qrencode ebuild with png use flag > > Please don't attach full ebuild and check out the copyright policy. My initial post was in a rush without reading up on how to submit changes to ebuilds (which I don't think I've ever done). I will make time in the next day or two to figure out the guidelines for submitting such a request; I'm sure it is easy to find. Thank you for your commitment.
Ok, I'm not against adding the flag but we should probably check revdeps now. After all, they could so far assume PNG support was there, and now they may need explicit [png] deps.
(In reply to Michał Górny from comment #6) > Ok, I'm not against adding the flag but we should probably check revdeps > now. After all, they could so far assume PNG support was there, and now > they may need explicit [png] deps. According to equery d qrencode there are two revdeps: kde-frameworks/prison sys-apps/systemd Both of these packages rely on libqrencode.so. libqrencode.so does not have any dependency on libpng. ldd /usr/lib64/libqrencode.so.4 linux-vdso.so.1 (0x00007ffd4bd52000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f41532b4000) libc.so.6 => /lib64/libc.so.6 (0x00007f415313b000) /lib64/ld-linux-x86-64.so.2 (0x00007f4153301000) Looking at qrencode, I can see that the --with{out}-png configure flag modulates HAVE_PNG. I see that HAVE_PNG is only referenced in qrenc.c. qrenc.c is not built into libqrencode.so. I also looked into systemd's use of libqrencode. I can see that systemd has contained use of libqrencode to qrcode-util.c, and is used by journalctl. Within qrcode-util.c there are two libqrencode functions dlsym'd: QRcode_encodeString & QRcode_free. Best I can tell, neither of these functions lead to any use of libpng. As for submitting the change to the ebuild, it looks like that is done via git pull requests now? Is there any other acceptable method to submit the 2-line change?
(In reply to rick vernam from comment #7) > (In reply to Michał Górny from comment #6) > > Ok, I'm not against adding the flag but we should probably check revdeps > > now. After all, they could so far assume PNG support was there, and now > > they may need explicit [png] deps. > > According to equery d qrencode there are two revdeps: > kde-frameworks/prison > sys-apps/systemd According to the lists at [1], there are more: app-admin/keepassxc app-admin/pass app-admin/pass-otp app-admin/passwordsafe app-crypt/tpm2-totp app-office/glabels kde-frameworks/prison net-im/dino net-im/openmittsu net-im/qtox net-im/toxic net-misc/oidc-agent net-p2p/bitcoin-qt sys-apps/systemd sys-auth/google-authenticator-libpam-hardened www-servers/pshs xfce-extra/xfce4-clipman-plugin I'm going to go through them today. [1] https://qa-reports.gentoo.org/output/genrdeps/ > > Both of these packages rely on libqrencode.so. libqrencode.so does not have > any dependency on libpng. > ldd /usr/lib64/libqrencode.so.4 > linux-vdso.so.1 (0x00007ffd4bd52000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f41532b4000) > libc.so.6 => /lib64/libc.so.6 (0x00007f415313b000) > /lib64/ld-linux-x86-64.so.2 (0x00007f4153301000) > > Looking at qrencode, I can see that the --with{out}-png configure flag > modulates HAVE_PNG. I see that HAVE_PNG is only referenced in qrenc.c. > qrenc.c is not built into libqrencode.so. Thanks, this is going to make it much easier for me ;-). > As for submitting the change to the ebuild, it looks like that is done via > git pull requests now? Is there any other acceptable method to submit the > 2-line change? You could attach git format patch or send it via email. However, this is trivial, so I can just do it myself after checking everything.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7a34377e3277a6a0e2eedd40e90452a44c55f1e6 commit 7a34377e3277a6a0e2eedd40e90452a44c55f1e6 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2022-02-14 11:59:35 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2022-02-14 12:01:23 +0000 media-gfx/qrencode: Add "png" flag Closes: https://bugs.gentoo.org/833147 Signed-off-by: Michał Górny <mgorny@gentoo.org> media-gfx/qrencode/metadata.xml | 3 +++ media-gfx/qrencode/qrencode-4.1.1.ebuild | 8 +++++--- 2 files changed, 8 insertions(+), 3 deletions(-)
Well, it turned out that app-admin/pass was the only package calling it via CLI, so just updated the deps in that one and pushed it.