Spec URL: https://decathorpe.fedorapeople.org/foundry.spec SRPM URL: https://decathorpe.fedorapeople.org/foundry-1.0~beta-1.fc42.src.rpm Description: This tool aims to extract much of what makes GNOME Builder an IDE into a library and companion command-line tool. Fedora Account System Username: decathorpe
koji scratch build for rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=135914385
Copr build: https://copr.fedorainfracloud.org/coprs/build/9395863 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2387518-foundry/fedora-rawhide-x86_64/09395863-foundry/fedora-review/review.txt Found issues: - License file foundry-license.h is not marked as %license Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text Please know that there can be false-positives. --- 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.
Thanks for packaging. This is approved. Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed Issues: ======= %{_libdir}/pkgconfig/libfoundry{,-gtk}-1.pc should move to the devel subpackage. I think the GPL-3.0-or-later license is probably a mistake that we should be able to remove. Created https://gitlab.gnome.org/GNOME/foundry/-/issues/14 to confirm. Let's wait for Christian to respond to this to make sure we get the License tag right. My recommendation is to removed the Provides: bundled(eggbitset) and bundled(timsort). I know it's sometimes hard to decide where to draw the line, but this seems too granular to me. It's a stretch to treat these little copylibs as equivalent to bundled libraries just because they happen to have their own meson.build and are two source files each instead of just one. You wisely don't add Provides for all the other egg files because it wouldn't scale well and the list would inevitably become stale. I've created https://gitlab.gnome.org/GNOME/foundry/-/issues/15 to request a man page and https://gitlab.gnome.org/GNOME/foundry/-/merge_requests/8 to placate the incorrect FSF address warning. ===== 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]: ldconfig not called in %post and %postun for Fedora 28 and later. [x]: Package does not contain any libtool archives (.la) [x]: Package contains no static executables. [x]: Rpath absent or only used for internal libs. [x]: Development (unversioned) .so files in -devel subpackage, if present. Generic: [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [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. Note: I removed fedora-review's comment here because it doesn't understand the foundry license API and is thinking that a bunch of random licenses apply. I manually ran fedora-review myself and inspected the licensecheck output. The only inconsistency I found is already fixed by https://gitlab.gnome.org/GNOME/foundry/-/commit/0a82a4e642c65de89fa3d4eec9efbfc9b53d150b [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. [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. [-]: Package contains desktop file if it is a GUI application. [!]: Development files must be in a -devel package [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. [ ]: Package does not generate any conflict. [x]: Package obeys FHS, except libexecdir and /usr/target. [-]: If the package is a rename of another package, proper Obsoletes and Provides are present. [-]: Requires correct, justified where necessary. [x]: Spec file is legible and written in American English. [-]: Package contains systemd file(s) if in need. [x]: Useful -debuginfo package or justification otherwise. [!]: Package is not known to require an ExcludeArch tag. Note: ExcludeArch for i686 is encouraged. The review criterion is wrong. [-]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 10399 bytes in 2 files. Note: The above comment is written by fedora-review. Not sure what it thinks is documentation. Probably false positive. [ ]: Package complies to the Packaging Guidelines [x]: Package installs properly. [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [x]: The License field must be a valid SPDX expression. [x]: Package requires other packages for directories it uses. [x]: Package must own all directories that it creates. [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]: Dist tag is present. [x]: Package does not contain duplicates in %files. [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: [x]: Reviewer should test that the package builds in mock. [-]: 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). [ ]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [x]: The placement of pkgconfig(.pc) files are correct. Note: foundry : /usr/lib64/pkgconfig/libfoundry-1.pc foundry : /usr/lib64/pkgconfig/libfoundry-gtk-1.pc [-]: Sources are verified with gpgverify first in %prep if upstream publishes signatures. Note: gpgverify is not used. Note: GNOME doesn't publish signatures. [-]: Package should compile and build into binary rpms on all supported architectures. Note: not evaluated for most architectures. Fail because i686 is intentionally excluded. [x]: %check is present and all tests pass. [ ]: Packages should try to preserve timestamps of original installed files. [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: [x]: Large data in /usr/share should live in a noarch subpackage if package is arched. Note: Arch-ed rpms have a total of 1955840 bytes in /usr/share Note: I think this is not big enough to warrant creating a noarch subpackage. [x]: Rpmlint is run on debuginfo package(s). Note: No rpmlint messages. [x]: Rpmlint is run on all installed packages. Note: No rpmlint messages. Note: I think fedora-review's use of rpmlint has been broken for a long time. I think it's only running on the SRPM rather than on installed packages. Rpmlint ------- Checking: foundry-1.0~beta-1.fc43.x86_64.rpm foundry-devel-1.0~beta-1.fc43.x86_64.rpm foundry-1.0~beta-1.fc43.src.rpm ============================ rpmlint session starts ============================ rpmlint: 2.7.0 configuration: /usr/lib/python3.13/site-packages/rpmlint/configdefaults.toml /etc/xdg/rpmlint/fedora-spdx-licenses.toml /etc/xdg/rpmlint/fedora.toml /etc/xdg/rpmlint/scoring.toml /etc/xdg/rpmlint/users-groups.toml /etc/xdg/rpmlint/warn-on-functions.toml rpmlintrc: [PosixPath('/tmp/tmp8irwfls_')] checks: 32, packages: 3 foundry.x86_64: W: no-manual-page-for-binary foundry foundry-devel.x86_64: W: no-documentation foundry.x86_64: E: incorrect-fsf-address /usr/share/licenses/foundry/COPYING foundry.x86_64: W: devel-file-in-non-devel-package /usr/lib64/pkgconfig/libfoundry-1.pc foundry.x86_64: W: devel-file-in-non-devel-package /usr/lib64/pkgconfig/libfoundry-gtk-1.pc 3 packages and 0 specfiles checked; 1 errors, 4 warnings, 29 filtered, 1 badness; has taken 0.7 s Rpmlint (debuginfo) ------------------- Checking: foundry-debuginfo-1.0~beta-1.fc43.x86_64.rpm ============================ rpmlint session starts ============================ rpmlint: 2.7.0 configuration: /usr/lib/python3.13/site-packages/rpmlint/configdefaults.toml /etc/xdg/rpmlint/fedora-spdx-licenses.toml /etc/xdg/rpmlint/fedora.toml /etc/xdg/rpmlint/scoring.toml /etc/xdg/rpmlint/users-groups.toml /etc/xdg/rpmlint/warn-on-functions.toml rpmlintrc: [PosixPath('/tmp/tmpvhlx249l')] checks: 32, packages: 1 1 packages and 0 specfiles checked; 0 errors, 0 warnings, 14 filtered, 0 badness; has taken 0.7 s Rpmlint (installed packages) ---------------------------- (none): E: there is no installed rpm "foundry-debuginfo". (none): E: there is no installed rpm "foundry-devel". ============================ rpmlint session starts ============================ rpmlint: 2.7.0 configuration: /usr/lib/python3.14/site-packages/rpmlint/configdefaults.toml /etc/xdg/rpmlint/fedora-spdx-licenses.toml /etc/xdg/rpmlint/fedora.toml /etc/xdg/rpmlint/scoring.toml /etc/xdg/rpmlint/users-groups.toml /etc/xdg/rpmlint/warn-on-functions.toml checks: 32, packages: 3 0 packages and 0 specfiles checked; 0 errors, 0 warnings, 0 filtered, 0 badness; has taken 0.0 s (none): E: there is no installed rpm "foundry". There are no files to process nor additional arguments. Nothing to do, aborting. Source checksums ---------------- https://download.gnome.org/sources/foundry/1.0/foundry-1.0.beta.tar.xz : CHECKSUM(SHA256) this package : 1a80ecbbfb9e3c3ecc834e98cc4fea20145068e5d8cae3cb781c7cede766a8bd CHECKSUM(SHA256) upstream package : 1a80ecbbfb9e3c3ecc834e98cc4fea20145068e5d8cae3cb781c7cede766a8bd Requires -------- foundry (rpmlib, GLIBC filtered): /usr/bin/pkg-config libc.so.6()(64bit) libcmark.so.0.30.3()(64bit) libdex-1.so.1()(64bit) libflatpak.so.0()(64bit) libfoundry-1.so.1()(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libgcc_s.so.1(GCC_3.3.1)(64bit) libgio-2.0.so.0()(64bit) libgit2.so.1.9()(64bit) libglib-2.0.so.0()(64bit) libgobject-2.0.so.0()(64bit) libgom-1.0.so.0()(64bit) libgtk-4.so.1()(64bit) libgtksourceview-5.so.0()(64bit) libjson-glib-1.0.so.0()(64bit) libjson-glib-1.0.so.0(libjson-glib-1.0.so.0)(64bit) libm.so.6()(64bit) libpango-1.0.so.0()(64bit) libpeas-2.so.0()(64bit) libspelling-1.so.2()(64bit) libtemplate_glib-1.0.so.0()(64bit) libvte-2.91-gtk4.so.0()(64bit) libwebkitgtk-6.0.so.4()(64bit) libxml2.so.2()(64bit) libxml2.so.2(LIBXML2_2.4.30)(64bit) libxml2.so.2(LIBXML2_2.5.0)(64bit) libxml2.so.2(LIBXML2_2.5.2)(64bit) libxml2.so.2(LIBXML2_2.5.7)(64bit) libxml2.so.2(LIBXML2_2.6.0)(64bit) libyaml-0.so.2()(64bit) pkgconfig(flatpak) pkgconfig(gio-2.0) pkgconfig(gio-unix-2.0) pkgconfig(gom-1.0) pkgconfig(gtk4) pkgconfig(gtksourceview-5) pkgconfig(json-glib-1.0) pkgconfig(libcmark) pkgconfig(libdex-1) pkgconfig(libfoundry-1) pkgconfig(libgit2) pkgconfig(libpeas-2) pkgconfig(libspelling-1) pkgconfig(libssh2) pkgconfig(libxml-2.0) pkgconfig(sysprof-capture-4) pkgconfig(template-glib-1.0) pkgconfig(vte-2.91-gtk4) pkgconfig(webkitgtk-6.0) pkgconfig(yaml-0.1) rtld(GNU_HASH) foundry-devel (rpmlib, GLIBC filtered): foundry(x86-64) libfoundry-1.so.1()(64bit) libfoundry-gtk-1.so.1()(64bit) Provides -------- foundry: bundled(eggbitset) bundled(timsort) foundry foundry(x86-64) libfoundry-1.so.1()(64bit) libfoundry-gtk-1.so.1()(64bit) pkgconfig(libfoundry-1) pkgconfig(libfoundry-gtk-1) foundry-devel: foundry-devel foundry-devel(x86-64)
LGPLv2.1+ is definitely the intended license. Anything that is not is an accident. I do want to suggest that things get broken up into the following: * "foundry" CLI tool (which statically links libfoundry) * "libfoundry" and "libfoundry-devel" which is just the core API (e.g. no GTK integration) * "libfoundry-gtk" and "libfoundry-gtk-devel" which is the GTK integration
(In reply to Christian Hergert from comment #4) > LGPLv2.1+ is definitely the intended license. Anything that is not is an > accident. Thanks. eggbitset and timsort are both Apache-2.0, so you would need to remove them both if you want LGPLv2.1+ to be the only license. > I do want to suggest that things get broken up into the following: > > * "foundry" CLI tool (which statically links libfoundry) > * "libfoundry" and "libfoundry-devel" which is just the core API (e.g. no > GTK integration) > * "libfoundry-gtk" and "libfoundry-gtk-devel" which is the GTK integration Sounds reasonable. I doubt Fabio will object to that? This is a significant change, so I'll review this again after the subpackages have been added.
(In reply to Michael Catanzaro from comment #3) > My recommendation is to removed the Provides: bundled(eggbitset) and > bundled(timsort). For avoidance of doubt: I recommend we remove the Provides. (I don't care whether upstream keeps these files and the Apache-2.0 license or not. That doesn't cause any problems.)
> eggbitset and timsort are both Apache-2.0, so you would need to remove them both if you want LGPLv2.1+ to be the only license. How is that handled in GTK? Both of those files come from GTK (though s/gtk/egg/g for bitset). $ sudo dnf info gtk4 ... Name : gtk4 ... License : LGPL-2.0-or-later
The gtk4 package's license field is wrong and should be fixed. (This is *very* common. Never actually trust the license field. If they are ever correct, then they'll become outdated before long. But at least we can get it correct when the package is reviewed!)
(I decided to actually work on updating the gtk4 package's license. I think it will look approximately like this: LGPL-2.0-or-later AND LGPL-2.1-or-later AND Apache-2.0 AND CC0-1.0 AND MIT AND MIT-open-group AND GPL-1.0-or-later AND GPL-2.0-or-later AND GPL-3.0-or-later AND HPND-sell-variant AND OFL-1.1-no-RFN But I'm not ready to create a pull request yet, because there are a few problems to fix upstream first.)
I created https://src.fedoraproject.org/rpms/gtk4/pull-request/21 to correct the gtk4 package's license field, following the rules in https://docs.fedoraproject.org/en-US/legal/license-field/ which do not allow us to "simplify" the license. Reviews are welcome from anybody brave enough to attempt it.
> "foundry" CLI tool (which statically links libfoundry) Why does it statically link it? From a distro perspective, libfoundry is "right there". There are some files — translations (don't exist yet but the framework is in place so they are coming soon), gsettings schemas, and perhaps /usr/share/foundry/language-defaults — that I believe are needed by both foundry and libfoundry. Debian has a convention of using a "-common" binary package for this situation but I guess this is uncommon 😉 in Fedora. If it wasn't statically linked, you could just have libfoundry supply these files and have foundry depend on libfoundry and I believe things would work.
It's probably fine at this point to dynamically link to `libfoundry`. Ultimately, I had a long term goal of being able to "push" the binary to an external system like an agent/remote-control for remove development. But for the 1.0, we're just not there yet. Also, statically linking anything with glib/glibc involved is a nightmare.
Currently, if we changed to shared library, we'll get a link failure: /usr/bin/ld: foundry.p/foundry.c.o: in function `shutdown_cb': /home/christian/Projects/foundry/build/../foundry.c:40:(.text+0x4b): undefined reference to `_foundry_context_shutdown_all' but we can probably work around that with an exported (but private) API.
https://gitlab.gnome.org/GNOME/foundry/-/commit/4f0a7de8ac2227571048ad45dcbcbc9c0c9d8136 https://gitlab.gnome.org/GNOME/foundry/-/commit/6b8c9814ade325a18eccca4e5b485e0c6cd5a044 Should fix things to be dynamically linked.
Thanks. Dynamic linking is certainly better. (In reply to Christian Hergert from comment #4) > * "foundry" CLI tool (which statically links libfoundry) > * "libfoundry" and "libfoundry-devel" which is just the core API (e.g. no > GTK integration) > * "libfoundry-gtk" and "libfoundry-gtk-devel" which is the GTK integration Looks like we still need to implement this subpackage split.
Sorry for the radio silence here - getting a new package reviewed has been very low priority with updates for existing packages being more important. Thank you both for your comments, I'll be making some adjustments to address the feedback in the previous comments, and bump the package to the 1.0.0 final release. > %{_libdir}/pkgconfig/libfoundry{,-gtk}-1.pc should move to the devel subpackage(s). Good catch, I added this to the wrong package. I moved it to the -devel package. > I think the GPL-3.0-or-later license is probably a mistake that we should be able to remove. Created https://gitlab.gnome.org/GNOME/foundry/-/issues/14 to confirm. Let's wait for Christian to respond to this to make sure we get the License tag right. Looks like this was resolved upstream between the 1.0.beta and the 1.0.0 release, I've adjusted the License tag accordingly. Thank you for filing the upstream ticket! > My recommendation is to removed the Provides: bundled(eggbitset) and bundled(timsort). I know it's sometimes hard to decide where to draw the line, but this seems too granular to me. It's a stretch to treat these little copylibs as equivalent to bundled libraries just because they happen to have their own meson.build and are two source files each instead of just one. You wisely don't add Provides for all the other egg files because it wouldn't scale well and the list would inevitably become stale. IMO having bundled "Provides" is *exactly* what you *should* do for copylibs. But to be fair, I really wasn't sure where / how to draw the line which ones to add, since it's a bit hard to tell where those even come from. "timsort" is just so ubiquitous that a web search didn't help at all. I'm fine with removing them if you think it makes more sense to draw the line of "what constitutes a bundled library" to the left of eggbitset and timsort :) > I've created https://gitlab.gnome.org/GNOME/foundry/-/issues/15 to request a man page and https://gitlab.gnome.org/GNOME/foundry/-/merge_requests/8 to placate the incorrect FSF address warning. Thank you! As for the package split - I will try to work on that, and will upload updated .spec and SRPM files when that's ready.
This timsort was copied from GTK. https://salsa.debian.org/gnome-team/foundry/-/blob/debian/latest/debian/copyright#L44
Spec URL: https://decathorpe.fedorapeople.org/foundry.spec SRPM URL: https://decathorpe.fedorapeople.org/foundry-1.0.0-1.fc42.src.rpm - updated to version 1.0.0 - moved .pc file to -devel subpackages - removed bundled() Provides for some stuff - split subpackages into libfoundry, libfoundry-gtk, libfoundry-devel, and libfoundry-gtk-devel, based on upstream recommendation Some things that I was not sure about: 1. What are the GSettings schemas used for? Are they used by the library, or only by the CLI? I've currently put them into the libfoundry package (which is the bottom of the dependency tree), so as it is now, they would always be availalable regardless of which packages are installed (which is the safest approach). 2. What is /usr/share/foundry/language-defaults thing used for? CLI or library? (basically, same question as 1.) 3. What is /usr/lib*/libfoundry-1/include/libfoundry-config.h for? It's a C header file that's installed in a rather unusual location. Right now I've put /usr/lib*/libfoundry-1/ directory and all its contents into libfoundry-devel. Is that correct? Or is that header file used at runtime by foundry CLI / libfoundry too?
Created attachment 2106959 [details] The .spec file difference from Copr build 9395863 to 9571305
Copr build: https://copr.fedorainfracloud.org/coprs/build/9571305 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2387518-foundry/fedora-rawhide-x86_64/09571305-foundry/fedora-review/review.txt Found issues: - License file foundry-license.h is not marked as %license Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text Please know that there can be false-positives. --- 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.
> - License file foundry-license.h is not marked as %license FoundryLicense represents a license, that can be selected in the project/etc. > What are the GSettings schemas used for? The library uses them. > What is /usr/share/foundry/language-defaults The library uses them for default language settings, allowing users to manually override. > What is /usr/lib*/libfoundry-1/include/libfoundry-config.h for? It's meant to be somewhat akin to the ${prefix}/lib*/glib-2.0/include/glibconfig.h
(In reply to Christian Hergert from comment #21) > > - License file foundry-license.h is not marked as %license > > FoundryLicense represents a license, that can be selected in the project/etc. :+1: > > What are the GSettings schemas used for? > > The library uses them. > > > What is /usr/share/foundry/language-defaults > > The library uses them for default language settings, allowing users to > manually override. Thanks for confirming, that means they're in the correct place already. > > What is /usr/lib*/libfoundry-1/include/libfoundry-config.h for? > > It's meant to be somewhat akin to the > ${prefix}/lib*/glib-2.0/include/glibconfig.h Let's ... assume that I don't know what that means? :)
>> It's meant to be somewhat akin to the >> ${prefix}/lib*/glib-2.0/include/glibconfig.h > > Let's ... assume that I don't know what that means? :) Right now it just has some compile time constants. But the eventual goal, is that is where our architecture-specific constants that require determination at compile time will go.
(In reply to Christian Hergert from comment #21) > It's meant to be somewhat akin to the > ${prefix}/lib*/glib-2.0/include/glibconfig.h I didn't know about this. The problem is the GLib header is architecture-dependent, so it can't go under /usr/include. I think the libfoundary header is not actually arch-dependent, but maybe it could be in the future, so the location seems reasonable. libfoundary-devel was the correct choice for where to put it.
Regarding the globs in the file list: %{_libdir}/libfoundry-1.so.1{,.0.0} %{_libdir}/libfoundry-gtk-1.so.1{,.0.0} Isn't this a little strict? Doesn't that mean we have to update the file list each time the library version changes at all? I think what we want to do is fail only if the first component of the library version changes, like: %{_libdir}/libfoundry-1.so.1{,.*} %{_libdir}/libfoundry-gtk-1.so.1{,.*} I don't see any other problems, so I'll approve this package.
Thanks for your feedback and the review! Regarding the ".1{,.0.0}" patterns -- I think you're right, but they're also not *wrong* right now, so I'll leave them as-is for now.
The Pagure repository was created at https://src.fedoraproject.org/rpms/foundry
Imported and built: https://bodhi.fedoraproject.org/updates/FEDORA-2025-867dc61fa6 The GNOME Manuals review should be unblocked (as soon as foundry is available in the rawhide repos).