Spec URL: https://bigmdm.fedorapeople.org/imsprog.spec SRPM URL: https://bigmdm.fedorapeople.org/imsprog-1.4.3-1.fc40.src.rpm SPEC URL2: https://raw.githubusercontent.com/bigbigmdm/SPEC-IMSProg/main/imsprog.spec Description: I2C, MicroWire and SPI EEPROM/Flash chip programmer with GUI is a program to read, write EEPROM chips using the CH341A programmer device. Fedora Account System Username:bigmdm I have added this package as a copr repo, and it has successfully built on all recent versions of Fedora Stream. Here is the link: https://copr.fedorainfracloud.org/coprs/bigmdm/imsprog/ Reproducible: Always
Please provide SRPM file as well. This will greatly simplifies reviewing. I advice you to use your <FAS>.fedorapeople.org space if no decent file sharing services comes to your mind. For example in my case (FAS - "peter") it is https://peter.fedorapeople.org. If you provided SSH public key in your FAS account you may use sshfs or scp to upload packages there. You may use your GitHub's keys for that (https://github.com/bigbigmdm.keys). Copr will work as well but the build artifacts will be GC'ed in a few weeks or months (don't know exactly) as soon as you do a new builds. Also please provide your FAS username - it it required for automatic review request processing. Please, provide builds for Rawhide as well - it's a recommended way and you have only ones for F39/F40: * https://copr.fedorainfracloud.org/coprs/bigmdm/IMSProg/build/7968658/
Also since you're using %autorelease you may find convenient to use %autochangelog as well.
Almost forgot - and welcome to Fedora community! We definitely need more people with electronics' hands-in experience!
One thing bothers me a bit. What's the proper packages name' capitalization what do you think? Still there is no consensus about it according to this link: * https://repology.org/project/imsprog/versions Maybe it's better to stick with lowercase option like Debian guys did? I don't have an opinion and prefer to use upstream's variant. (I suppose you are upstream, right?)
Actually the package in a very good shape, from a first glance I see only one (but actually a serious) issue - you absolutely need to add a licensing info. Please add "%license LICENSE" to the %files section. That's all. Do you have a sponsorship? If no then what's your FAS id?
Peter Lemenkov, thank you for your kind words and interest in my program. I am building it under Debian (with a lot of help from Fabio Fantoni). Yes, I really need a sponsor. Can you tell me if it is convenient to continue the discussion here, or is it better here (https://github.com/bigbigmdm/IMSProg/issues/19) ?
Oh, the copyright file is needed for Debian and is placed in the debian/latest branch, and the license file is placed in the root of the GitHub repository.
(In reply to Mikhail Medvedev from comment #6) > Peter Lemenkov, thank you for your kind words and interest in my program. I > am building it under Debian (with a lot of help from Fabio Fantoni). Yes, I > really need a sponsor. Can you tell me if it is convenient to continue the > discussion here, or is it better here > (https://github.com/bigbigmdm/IMSProg/issues/19) ? Let's continue discussing Fedora-related issues here :) Btw I've just sponsired you (added into packager's group). So anyone can review your package since now.
(In reply to Mikhail Medvedev from comment #7) > Oh, the copyright file is needed for Debian and is placed in the > debian/latest branch, and the license file is placed in the root of the > GitHub repository. We demand it as well. Fortunately as I said it's very easy to address.
Hello, Peter Lemenkov! What I did: 1. I added “%license LICENSE” to the specification file. 2. I enabled builds for Rawhide in the COPR settings. 3. I rebuilt the project. What I don't understand today: 1. if I want to change the project name to lowercase - do I need to rename the .spec file and create a new project in COPR? (I can't rename the current project - the project name field is not active). 2. I don't understand in your first post. Do I need to manually build IMSProg on my local computer and copy the SRPM file to https://bigmdm/fedorepeople.org ?
I transfered .spec and .SRPM files to https://bigmdm.fedorapeople.org/ Is it correct?
The ticket summary is not in the correct format. Expected: Review Request: <main package name here> - <short summary here> Found: Review request As a consequence, the package name cannot be parsed and submitted to be automatically build. Please modify the ticket summary and trigger a build by typing [fedora-review-service-build]. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
(In reply to Mikhail Medvedev from comment #10) > Hello, Peter Lemenkov! > What I did: > 1. I added “%license LICENSE” to the specification file. > 2. I enabled builds for Rawhide in the COPR settings. > 3. I rebuilt the project. Good! > What I don't understand today: > 1. if I want to change the project name to lowercase - do I need to rename > the .spec file and create a new project in COPR? (I can't rename the current > project - the project name field is not active). In this case yes, but I am not insisting on renaming. > 2. I don't understand in your first post. Do I need to manually build > IMSProg on my local computer and copy the SRPM file to > https://bigmdm/fedorepeople.org ? Correct. Actually you don't need to do a full rebuild. You may build only SRPM with ```rpmbuild -bs ./IMSProg.spec```. Spec URL: https://bigmdm.fedorapeople.org/IMSProg.spec SRPM URL: https://bigmdm.fedorapeople.org/IMSProg-1.4.3-1.fc40.src.rpm
A small thing - please remove outdated "Group: Devel" field.
I am going to review it.
Peter, please comment this: " Fedora Review Service 2024-09-08 15:02:02 UTC The ticket summary is not in the correct format. Expected: Review Request: <main package name here> - <short summary here> Found: Review request As a consequence, the package name cannot be parsed and submitted to be automatically build. Please modify the ticket summary and trigger a build by typing [fedora-review-service-build]." - I don't understand that.
The ticket summary is not in the correct format. Expected: Review Request: <main package name here> - <short summary here> Found: Review request: IMSProg - I2C, SPI, MicroWire and DataFlash EEPROM chip programmer for CH341a devices As a consequence, the package name cannot be parsed and submitted to be automatically build. Please modify the ticket summary and trigger a build by typing [fedora-review-service-build]. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
Peter Lemenkov, Fedora Review Service requires only small letters?
Peter Lemenkov, hello! I have created a new package - imsprog. I built it for f39, f40, rawhide. (I haven't removed the old IMSProg package yet). I have uploaded the .spec and SRPM files to https://bigmdm.fedorapeople.org/ Can you please advise me what else needs to be done?
(In reply to Mikhail Medvedev from comment #19) > Peter Lemenkov, hello! > I have created a new package - imsprog. I built it for f39, f40, rawhide. > (I haven't removed the old IMSProg package yet). > I have uploaded the .spec and SRPM files to https://bigmdm.fedorapeople.org/ > Can you please advise me what else needs to be done? Hey! Give me a moment - I'll look into this.
(to automate things) Spec URL: https://bigmdm.fedorapeople.org/imsprog.spec SRPM URL: https://bigmdm.fedorapeople.org/imsprog-1.4.3-1.fc39.src.rpm
Peter, maybe those lines should be copied into the first post?
Here are things which require your attention. * Consider removing outdated "Group: Devel" field. It's not a blocker but we stopped using it since Fedora 25. if you consider keeping it then the value is wrong. Here is a list of a valid values - https://fedoraproject.org/wiki/RPMGroups. * %license field needs some love. We need to reflect licensing information for *all* source files used to build artifacts we ship in a package. I see that most of the source code is licensed under GPLv3+ but at least part of the application is derived from flashrom source code which is licensed under GPLv2+ and some source files licensed under LGPLv2.1. Here is a licensing breakdown: ``` GNU General Public License v2.0 or later ---------------------------------------- ./IMSProg_editor/IMSProg_editor.pro ./IMSProg_editor/delegates.cpp ./IMSProg_editor/delegates.h ./IMSProg_editor/ezp_chip_editor.cpp ./IMSProg_editor/ezp_chip_editor.h ./IMSProg_programmer/ch341a_gpio.c ./IMSProg_programmer/ch341a_gpio.h ./IMSProg_programmer/ch341a_spi.c ./IMSProg_programmer/ch341a_spi.h ./IMSProg_programmer/dialogrp.h ./IMSProg_programmer/dialogsp.cpp ./IMSProg_programmer/dialogsp.h ./IMSProg_programmer/flashcmd_api.c ./IMSProg_programmer/flashcmd_api.h ./IMSProg_programmer/i2c_eeprom.c ./IMSProg_programmer/i2c_eeprom_api.h ./IMSProg_programmer/main.cpp ./IMSProg_programmer/mw_eeprom.c ./IMSProg_programmer/mw_eeprom_api.h ./IMSProg_programmer/nandcmd_api.h ./IMSProg_programmer/snorcmd_api.h ./IMSProg_programmer/spi_eeprom.c ./IMSProg_programmer/spi_eeprom.h ./IMSProg_programmer/spi_eeprom_api.h ./IMSProg_programmer/spi_nor_flash.c ./IMSProg_programmer/timer.c ./IMSProg_programmer/timer.h ./IMSProg_programmer/types.h GNU General Public License v2.0 or later [obsolete FSF postal address (Mass Ave)] --------------------------------------------------------------------------------- ./IMSProg_programmer/bitbang_microwire.c ./IMSProg_programmer/bitbang_microwire.h GNU General Public License v3.0 or later ---------------------------------------- ./IMSProg_programmer/ch341a_i2c.c ./IMSProg_programmer/ch341funcs.c ./IMSProg_programmer/dialogabout.cpp ./IMSProg_programmer/dialogabout.h ./IMSProg_programmer/dialoginfo.cpp ./IMSProg_programmer/dialoginfo.h ./IMSProg_programmer/dialogrp.cpp ./IMSProg_programmer/dialogsetaddr.cpp ./IMSProg_programmer/dialogsetaddr.h ./IMSProg_programmer/dialogsfdp.cpp ./IMSProg_programmer/dialogsfdp.h ./IMSProg_programmer/dialogsr.cpp ./IMSProg_programmer/dialogsr.h ./IMSProg_programmer/mainwindow.cpp ./IMSProg_programmer/mainwindow.h GNU Lesser General Public License, Version 2.1 ---------------------------------------------- ./IMSProg_programmer/chunks.cpp ./IMSProg_programmer/commands.cpp ./IMSProg_programmer/qhexedit.cpp ./IMSProg_programmer/searchdialog.cpp ./IMSProg_programmer/searchdialog.h ``` So a proper %license field value has to be "GPL-2.0-or-later AND GPL-3.0-or-later AND LGPL-2.1-only". * A small proposal - please move these lines from %prep section to %build section: ``` # update translations lrelease-qt5 IMSProg_editor/language/*.ts lrelease-qt5 IMSProg_programmer/language/*.ts ``` Sometimes it's very handy to run "rpmbuild -bp ./your.spec" without installing any dependencies. Just to check how patches are applied, look through unpacked source code, etc. basically everything which doesn't create a new build artifacts (sources patching, preparatory file renaming, etc - not very invasive) should go to %prep sections. Artifacts should be generated in %build section. * Your package installs desktop-files. We require that they have to be validated with desktop-file-validate. The same story with metainfo files - you have to validate them with appstream-util. Validation can be done in %install or %check sections at your choice. Take a look at these spec-files as a possible examples. ** https://src.fedoraproject.org/rpms/bitcoin-core/blob/rawhide/f/bitcoin-core.spec#_263 ** https://src.fedoraproject.org/rpms/mpv/blob/rawhide/f/mpv.spec#_189 ** https://src.fedoraproject.org/rpms/xchm/blob/rawhide/f/xchm.spec#_35 * A small doc-related issue. It seems that you listed %_docdir/imsprog/ explicitly. I don't think it is necessary. The contents of this directory is included already.
One mroe thing: ``` # remove extra appdata rm %buildroot%_datadir/metainfo/io.github.bigbigmdm.imsprog_database_update.metainfo.xml rm %buildroot%_datadir/metainfo/io.github.bigbigmdm.imsprog_editor.metainfo.xml ``` Are you sure these metainfo-files are not necessary?
Peter Lemenkov, hello! What was done: 1. The line “Group: Devel” was changed to “Group: Applications/Engineering” (line 15) 2. The translation commands update has been moved to the build section 3. Added “desktop-file-utils” to “BuildRequires” to check desktop files (line 26) 4. Added desktop files check to the “%check” section (line 169) 5. Added “libappstream-glib” to “BuildRequires” to check metadata files (line 26) 6. Added metadata files check to the “%check” section (line 171) 7. The imsprog has been rebuilded What I forgot: "Are you sure these metainfo-files are not necessary?" - Yes, you can keep them. Which I couldn't do: "* %license field needs some love. " If I add the "%license GPL-2.0-or-later AND GPL-3.0-or-later AND LGPL-2.1-only" command to the "%files" section, I get a message that the files don't exist. I don't understand how to do it correctly yet and I ask for your help.
8. Line 13 changed from "License: GPL-3.0" to "License: GPL-2.0-or-later AND GPL-3.0-or-later AND LGPL-2.1-only" 9. Canceled deletion of additional metadata 10. The imsprog has been rebuilded, new flies uploaded to https://bigmdm.fedorapeople.org/
Ok, I can't find any other issues so here is my formal Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed Issues: ======= - Package does not contain duplicates in %files. Note: warning: File listed twice: /usr/share/doc/imsprog See: https://docs.fedoraproject.org/en-US/packaging- guidelines/#_duplicate_files ^^^ I think this could be ignored. Your package installs files into the same directory where we install doc-files by default. ===== MUST items ===== C/C++: [x]: Package does not contain kernel modules. [x]: If your application is a C or C++ application you must list a BuildRequires against gcc, gcc-c++ or clang. [x]: Header files in -devel subpackage, if present. [x]: Package does not contain any libtool archives (.la) [x]: Package contains no static executables. [x]: Rpath absent or only used for internal libs. Generic: [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: License field in the package spec file matches the actual license. See our analysis above. [x]: License file installed when any subpackage combination is installed. [x/!]: If the package is under multiple licenses, the licensing breakdown must be documented in the spec but I don't think it's a practical thing in this case. [x]: Package owns all directories that it creates (or depends on them). [x]: %build honors applicable compiler flags or justifies otherwise. [x]: Package contains no bundled libraries without FPC exception. [x]: Changelog in prescribed format. [x]: Sources contain only permissible code or content. [-]: No development files. [x]: Package uses nothing in %doc for runtime. [x]: Package consistently uses macros (instead of hard-coded directory names). [x]: Package is named according to the Package Naming Guidelines. See our discussion about capitalization of the name above. [x]: Package does not generate any conflict. [x]: Package obeys FHS, except libexecdir and /usr/target. [-]: The package is not a rename of another package. [x]: Requires correct, justified where necessary. [x]: Spec file is legible and written in American English. [-]: Package does not contain systemd file(s). [x]: Useful -debuginfo package or justification otherwise. [x]: Package is not known to require an ExcludeArch tag. [-]: No extremely large documentation files. [x]: Package complies to the Packaging Guidelines [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: Package installs properly. [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [x]: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %license. [x]: The License field must be a valid SPDX expression. [x]: Package requires other packages for directories it uses. [x]: Package does not own files or directories owned by other packages. [x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Macros in Summary, %description expandable at SRPM build time. [x]: Package contains desktop file if it is a GUI application. [x]: Package installs a %{name}.desktop using desktop-file-install or desktop-file-validate if there is such a file. [x]: Dist tag is present. [x]: Permissions on files are set properly. [x]: Package must not depend on deprecated() packages. [x]: Package use %makeinstall only when make install DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: Package does not use a name that already exists. [x]: Package is not relocatable. [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. [x]: Packages must not store files under /srv, /opt or /usr/local ===== SHOULD items ===== Generic: [-]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: Final provides and requires are sane (see attachments). [?]: I did not test if the package functions as described. [x]: Latest version is packaged (1.4.3). [x]: Package does not include license text files separate from upstream. [-]: Sources weren't verified with gpgverify (upstream does not publish signatures. [x]: Package compiles and builds into binary rpms on all supported architectures. See Copr builds mentioned above. [x]: %check is present and all tests pass. [x]: Packages should try to preserve timestamps of original installed files. [x]: Reviewer should test that the package builds in mock. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Fully versioned dependency in subpackages if applicable. [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: Sources can be downloaded from URI in Source: tag [x]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [-]: Large data in /usr/share should live in a noarch subpackage if package is arched but I don't think there is that much noarch data. [x]: Rpmlint is run on debuginfo package(s). Note: There are rpmlint messages (see attachment). [x]: Rpmlint is run on all installed packages. Note: There are rpmlint messages (see attachment). Rpmlint ------- Cannot parse rpmlint output: Rpmlint (debuginfo) ------------------- Cannot parse rpmlint output: Rpmlint (installed packages) ---------------------------- Cannot parse rpmlint output: Source checksums ---------------- https://github.com/bigbigmdm/IMSProg/archive/refs/tags/v1.4.3.tar.gz : CHECKSUM(SHA256) this package : c1c26c5aeb83116b4a519f60a5c35deda296b14a16134dbbad159f8f62964079 CHECKSUM(SHA256) upstream package : c1c26c5aeb83116b4a519f60a5c35deda296b14a16134dbbad159f8f62964079 Requires -------- imsprog (rpmlib, GLIBC filtered): /usr/bin/bash libQt5Core.so.5()(64bit) libQt5Core.so.5(Qt_5)(64bit) libQt5Core.so.5(Qt_5.15)(64bit) libQt5Gui.so.5()(64bit) libQt5Gui.so.5(Qt_5)(64bit) libQt5Widgets.so.5()(64bit) libQt5Widgets.so.5(Qt_5)(64bit) libc.so.6()(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libgcc_s.so.1(GCC_3.3.1)(64bit) libstdc++.so.6()(64bit) libstdc++.so.6(CXXABI_1.3)(64bit) libstdc++.so.6(CXXABI_1.3.9)(64bit) libusb-1.0.so.0()(64bit) rtld(GNU_HASH) imsprog-debuginfo (rpmlib, GLIBC filtered): imsprog-debugsource (rpmlib, GLIBC filtered): Provides -------- imsprog: application() application(IMSProg.desktop) application(IMSProg_database_update.desktop) application(IMSProg_editor.desktop) imsprog imsprog(x86-64) metainfo() metainfo(io.github.bigbigmdm.imsprog.metainfo.xml) metainfo(io.github.bigbigmdm.imsprog_database_update.metainfo.xml) metainfo(io.github.bigbigmdm.imsprog_editor.metainfo.xml) imsprog-debuginfo: debuginfo(build-id) imsprog-debuginfo imsprog-debuginfo(x86-64) imsprog-debugsource: imsprog-debugsource imsprog-debugsource(x86-64) Generated by fedora-review 0.10.0 (e79b66b) last change: 2023-07-24 Command line :/usr/bin/fedora-review --rpm-spec -n /home/petro/rpmbuild/SRPMS/imsprog-1.4.3-1.fc40.src.rpm Buildroot used: fedora-rawhide-x86_64 Active plugins: C/C++, Generic, Shell-api Disabled plugins: PHP, SugarActivity, Ocaml, Perl, Java, Python, Haskell, R, fonts Disabled flags: EXARCH, EPEL6, EPEL7, DISTTAG, BATCH Ok, perhaps there are some other minor issues but we'd better deal with them later. This package is ================ === APPROVED === ================ You have a go! https://www.youtube.com/watch?v=odiMeEhfi9I
Thank you, Peter!!!
Peter, can you please tell me if there's anything else I need to do here?
(In reply to Mikhail Medvedev from comment #29) > Peter, can you please tell me if there's anything else I need to do here? Yes, unfortunately there are things only you can do. * You need to create a repository at src.fedoraproject.org. Just type ```fedpkg request-repo imsprog 2310622```. This command will create an issue which will be addressed in a few minutes by a person. After this you'll have a clonable repository but with only a single branch available - rawhide. * Now you need to request an extra branches (available active ones are f41, f40, f39). Just type ```fedpkg request-branch --repo imsprog f40``` (for f40 extra branch). It will create issue which will be addressed quite fast - in a few seconds. * Now you're ready to clone your repository with ```fedpkg clone imsprog```. It will execute git clone with a proper parameters so you'll have a regular git repository. * Now upload a latest src.rpm - ```fedpkg upload /path/to/your/package.src.rpm``` * ```git commit -a -m "a descriptive message"``` * ```git push``` * ```fedpkg build``` * ```fedpkg update``` or use Bodhi web interface for that - https://bodhi.fedoraproject.org/updates/new. That's mostly all. If you have any questions then don't hesitate to ask me directly! Further reading: * https://docs.fedoraproject.org/en-US/package-maintainers/New_Package_Process_for_New_Contributors/ * https://docs.fedoraproject.org/en-US/package-maintainers/Package_Maintenance_Guide/ * https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/
Thank you, Peter!
The Pagure repository was created at https://src.fedoraproject.org/rpms/imsprog
Hello, Peter! I need some help. I have created branches in https://src.fedoraproject.org/rpms/imsprog. I have moved spec and src files to all branches. But `fedpkg build` returns error status: https://kojipkgs.fedoraproject.org//work/tasks/2668/123292668/build.log. My telegram is @bigmdm Regards, Mikhail Medvedev
FEDORA-2024-2f242e7e78 (imsprog-1.4.3-3.fc39) has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-2f242e7e78
FEDORA-2024-5e7bf4bd5a (imsprog-1.4.3-3.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-5e7bf4bd5a
FEDORA-2024-bb8870f2f1 (imsprog-1.4.3-3.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-bb8870f2f1
FEDORA-2024-bb8870f2f1 has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf install --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-bb8870f2f1 \*` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-bb8870f2f1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-5e7bf4bd5a has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf install --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-5e7bf4bd5a \*` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-5e7bf4bd5a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-2f242e7e78 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf install --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-2f242e7e78 \*` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-2f242e7e78 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-bb8870f2f1 (imsprog-1.4.3-3.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-2f242e7e78 (imsprog-1.4.3-3.fc39) has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-5e7bf4bd5a (imsprog-1.4.3-3.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.