Bug 2049400

Spec URL: https://davdunc.fedorapeople.org/awscli-2-rpms/aws-c-cal.spec
SRPM URL: https://davdunc.fedorapeople.org/awscli-2-rpms/aws-c-cal-0.5.12-4.fc35.src.rpm

Updated based on requirements for aws-c-common bz#2049379

SRPM URL: https://davdunc.fedorapeople.org/awscli-2-rpms/aws-c-cal-0.5.12-6.fc35.src.rpm
Spec URL: https://davdunc.fedorapeople.org/awscli-2-rpms/aws-c-cal.spec

Taking this review

This is a review *template*. Besides handling the [ ]-marked tests you are
also supposed to fix the template before pasting into bugzilla:
- Add issues you find to the list of issues on top. If there isn't such
  a list, create one.
- Add your own remarks to the template checks.
- Add new lines marked [!] or [?] when you discover new things not
  listed by fedora-review.
- Change or remove any text in the template which is plain wrong. In this
  case you could also file a bug against fedora-review
- Remove the "[ ] Manual check required", you will not have any such lines
  in what you paste.
- Remove attachments which you deem not really useful (the rpmlint
  ones are mandatory, though)
- Remove this text



Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed



===== MUST items =====

C/C++:
[x]: Package does not contain kernel modules.
[x]: Package contains no static executables.
[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]: Rpath absent or only used for internal libs.
[x]: Development (unversioned) .so files in -devel subpackage, if present.

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.
     Note: Checking patched sources after %prep for licenses. Licenses
     found: "Unknown or generated", "Apache License 2.0", "*No copyright*
     Apache License 2.0". 14 files have unknown license. Detailed output of
     licensecheck in /tmp/2049400-aws-c-cal/licensecheck.txt
[x]: License file installed when any subpackage combination is installed.
[!]: Package must own all directories that it creates.
     Note: Directories without known owners: /usr/include/aws
[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.
[x]: 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.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[x]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: 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.
[x]: Package is not known to require an ExcludeArch tag.
[x]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 10240 bytes in 1 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]: 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]: 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:
[-]: 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).
[x]: Fully versioned dependency in subpackages if applicable.
     Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in aws-c-
     cal-libs , aws-c-cal-devel
[?]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[-]: Patches link to upstream bugs/comments/lists or are otherwise
     justified.
[-]: Sources are verified with gpgverify first in %prep if upstream
     publishes signatures.
     Note: gpgverify is not used.
[-]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[!]: %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]: 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]: 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).
[x]: Large data in /usr/share should live in a noarch subpackage if package
     is arched.
[x]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Cannot parse rpmlint output:


Rpmlint (debuginfo)
-------------------
Cannot parse rpmlint output:



Rpmlint (installed packages)
----------------------------
Cannot parse rpmlint output:


Source checksums
----------------
https://github.com/awslabs/aws-c-cal/archive/v0.5.12/aws-c-cal-0.5.12.tar.gz :
  CHECKSUM(SHA256) this package     : 350c29a288d5d498bd6574fca659cffc9453bf62691fbde5788399716c2bd132
  CHECKSUM(SHA256) upstream package : 350c29a288d5d498bd6574fca659cffc9453bf62691fbde5788399716c2bd132


Requires
--------
aws-c-cal (rpmlib, GLIBC filtered):
    aws-c-cal-libs(x86-64)
    aws-c-common-libs
    libaws-c-cal.so.1.0.0()(64bit)
    libaws-c-common.so.1()(64bit)
    libc.so.6()(64bit)
    openssl
    rtld(GNU_HASH)

aws-c-cal-libs (rpmlib, GLIBC filtered):
    libaws-c-common.so.1()(64bit)
    libc.so.6()(64bit)
    libcrypto.so.3()(64bit)
    libcrypto.so.3(OPENSSL_3.0.0)(64bit)
    rtld(GNU_HASH)

aws-c-cal-devel (rpmlib, GLIBC filtered):
    aws-c-cal-libs(x86-64)
    cmake-filesystem(x86-64)
    libaws-c-cal.so.1.0.0()(64bit)

aws-c-cal-debuginfo (rpmlib, GLIBC filtered):

aws-c-cal-debugsource (rpmlib, GLIBC filtered):



Provides
--------
aws-c-cal:
    aws-c-cal
    aws-c-cal(x86-64)

aws-c-cal-libs:
    aws-c-cal-libs
    aws-c-cal-libs(x86-64)
    libaws-c-cal.so.1.0.0()(64bit)

aws-c-cal-devel:
    aws-c-cal-devel
    aws-c-cal-devel(x86-64)
    cmake(aws-c-cal)

aws-c-cal-debuginfo:
    aws-c-cal-debuginfo
    aws-c-cal-debuginfo(x86-64)
    debuginfo(build-id)

aws-c-cal-debugsource:
    aws-c-cal-debugsource
    aws-c-cal-debugsource(x86-64)



Generated by fedora-review 0.7.6 (b083f91) last change: 2020-11-10
Command line :/usr/bin/fedora-review -b 2049400 -o --enablerepo local
Buildroot used: fedora-rawhide-x86_64
Active plugins: Generic, C/C++, Shell-api
Disabled plugins: Haskell, SugarActivity, R, Perl, Python, Java, PHP, fonts, Ocaml
Disabled flags: EPEL6, EPEL7, DISTTAG, BATCH, EXARCH

For:

[!]: Package must own all directories that it creates.
     Note: Directories without known owners: /usr/include/aws

I'd recommend making the -devel package Require: aws-c-common-devel , assuming that's where this comes from.

In addition, while:

[!]: %check is present and all tests pass.

isn't mandatory you may wanna add a

%check
%ctest

section if there's any useful tests shipped.

Thanks! there are some helpful tests in ctest. I'll update the dependencies for -devel.

SRPM URL: https://davdunc.fedorapeople.org/awscli-2-rpms/aws-c-cal-0.5.12-7.fc35.src.rpm
Spec URL: https://davdunc.fedorapeople.org/awscli-2-rpms/aws-c-cal.spec

Thanks, APPROVED

This package was never imported despite being approved and the repository created.
Are you willing to finalize the process?

I don't think the process should continue, as aws-c-cal is now packaged as part of python-awscrt (bug #2179888).

I don't like the way that python-awscrt bundles all of the component c libraries as it does not cover all potential cases for use I would like them to cover. That said, there are no other applications dependent on the crt libraries besides the awscli2 in the fedora packages. I would argue that it is bundled in python-awscrt and that is the practical way to handle it for awscli2, but I would rather maintain it speparately.

I have to do some more research to understand the history of those decisions.

But I'm wondering about:
> I don't think the process should continue, as aws-c-cal is now packaged as part of python-awscrt (bug #2179888).

There are a lot more aws-crt libs out there (aws-crt-ruby, aws-crt-php, aws-crt-nodejs, aws-crt-kotlin, aws-crt-java, aws-crt-dotnet and aws-crt-cpp).
This decision means we would have to bundle the libs with any of them if it would be build for Fedora?

Based on https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling I understand we CAN do it but it wouldn't be reasonable.
Separate aws-c-* packages mean we can re-use them for python-awscrt and all others right? Sounds like a much better approach then.

I want to keep aws-php-sdk3 alive (https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/X6X4YMIY3PHURRPZOH5VEGUCWTORFUVF/) and one dependency of the newest version is aws-crt-php 
Which has dependencies to 9 aws* libraries (aws-crt-ffi, aws-c-auth, aws-c-http, aws-c-io, aws-c-cal, aws-c-compression, aws-checksums, aws-c-sdkutils, aws-c-common).
My plan to tackle this package was to create separate ones for each library dependency.
Now I'm not sure anymore, it looks like some of them have open review request but stuck because of python-awscrt already ships them?

(In reply to Dominik Wombacher from comment #12)
> Based on https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling
> I understand we CAN do it but it wouldn't be reasonable.
> Separate aws-c-* packages mean we can re-use them for python-awscrt and all
> others right? Sounds like a much better approach then.

As far as aws-crt-python is concerned, upstream doesn't want to depend on specific versions of dynamic libraries and rather pulls in specific revisions of the libraries and links them statically.
 
> Now I'm not sure anymore, it looks like some of them have open review
> request but stuck because of python-awscrt already ships them?

Technically it doesn't ship the libraries, it ships _awscrt.abiN.so the libraries are statically linked into.

I think it is possible for python-awscrt to bundle the libraries and at the same time have them packaged separately, is it not?

(In reply to Nikola Forró from comment #13)
> As far as aws-crt-python is concerned, upstream doesn't want to depend on
> specific versions of dynamic libraries and rather pulls in specific
> revisions of the libraries and links them statically.

You are right, for aws-crt-python it looks like that all aws lib dependencies come from git-submodules.

> Technically it doesn't ship the libraries, it ships _awscrt.abiN.so the
> libraries are statically linked into.

True, so from a packaging Guideline perspective this falls then somehow under https://docs.fedoraproject.org/en-US/packaging-guidelines/#_packaging_static_libraries ?
Or is it bundled when it's linked against fedora external packages/sources and static libraries if they exist as package in fedora?

> I think it is possible for python-awscrt to bundle the libraries and at the
> same time have them packaged separately, is it not?

Yes it is, I guess that's why I was a bit confused about your comment that packaging of aws-c-cal shouldn't proceed.

So that means, there is no reason not to finalize the process and add aws-c-cal to the already created repo? 
And we should actually do the same with the rest of the libraries and if possible use them during package building?

(In reply to Dominik Wombacher from comment #14)
> True, so from a packaging Guideline perspective this falls then somehow
> under https://docs.fedoraproject.org/en-US/packaging-guidelines/#_packaging_static_libraries ?
> Or is it bundled when it's linked against fedora external packages/sources
> and static libraries if they exist as package in fedora?

I'm not sure to be honest, but I think it still falls under bundling.

> Yes it is, I guess that's why I was a bit confused about your comment that
> packaging of aws-c-cal shouldn't proceed.

Right, sorry, I didn't mean I have anything against packaging aws-c-cal separately, but I was under the impression that David initially intended to package aws-crt-python the "proper" way and this review request was the first step toward that, and when that idea was abandoned and aws-crt-python packaged the way it is, the review request no longer made sense.

> So that means, there is no reason not to finalize the process and add
> aws-c-cal to the already created repo? 
> And we should actually do the same with the rest of the libraries and if
> possible use them during package building?

I would say so.

(In reply to Nikola Forró from comment #15)
> (In reply to Dominik Wombacher from comment #14)
>
> Right, sorry, I didn't mean I have anything against packaging aws-c-cal
> separately, but I was under the impression that David initially intended to
> package aws-crt-python the "proper" way and this review request was the
> first step toward that, and when that idea was abandoned and aws-crt-python
> packaged the way it is, the review request no longer made sense.
> 

Ah ok, yeah could be possible, it's been a while. 

> > So that means, there is no reason not to finalize the process and add
> > aws-c-cal to the already created repo? 
> > And we should actually do the same with the rest of the libraries and if
> > possible use them during package building?
> 
> I would say so.

Sounds good. There are more and more packages that leverage some of the AWS C libs.
I'm on my way to brush up old spec files and raise new requests for the different libs.

Regarding this one, aws-c-cal: 
Should I, on behalf of David Duncan, attach an updated spec and srpm based on latest upstream to process with the import into https://src.fedoraproject.org/rpms/aws-c-cal ?
Or is the process to import the files that were originally approved and then update the package as soon it's imported in dist-git?
Who can do the import? What's the next step?

(In reply to Dominik Wombacher from comment #16)
> Regarding this one, aws-c-cal: 
> Should I, on behalf of David Duncan, attach an updated spec and srpm based
> on latest upstream to process with the import into
> https://src.fedoraproject.org/rpms/aws-c-cal ?
> Or is the process to import the files that were originally approved and then
> update the package as soon it's imported in dist-git?
> Who can do the import? What's the next step?

I would suggest to sync with David Duncan, he's the main admin of the dist-git repo and can give you access, then you can proceed with the import. In my opinion it makes no sense to import the originally approved files first.

(In reply to Nikola Forró from comment #17)
> 
> I would suggest to sync with David Duncan, he's the main admin of the
> dist-git repo and can give you access, then you can proceed with the import.
> In my opinion it makes no sense to import the originally approved files
> first.

Agree. I had a call with David. 
We going to update aws-c-common to the latest version. It's a dependency to update aws-c-cal.
In parallel, we have to sort out the package group sponsor topic for me. 
Otherwise he can't add me as co-maintainer.
When that's done I will import aws-c-cal in an updated version.
I don't expect fundamental changes with the package.
It should still be pretty close to what was approved.

Hey everyone.

aws-c-cal is imported [1] based on a slightly updated spec file that use the latest upstream release.
The dist-git repo is onboarded to Packit [2][3].
The update for rawhide submitted [4].

Thanks Nikola for your valuable feedback to move things forward and Duncan for trusting me with the package import and update.

Going to close this Bug as per [5].

Dom


[1] https://src.fedoraproject.org/rpms/aws-c-cal/c/e79764025441dd4616bc8fdbd18ebe72f7e18b2b?branch=rawhide
[2] https://src.fedoraproject.org/rpms/aws-c-cal/blob/rawhide/f/.packit.yaml
[3] https://release-monitoring.org/project/141683/
[4] https://bodhi.fedoraproject.org/updates/FEDORA-2024-294fb812fe
[5] https://docs.fedoraproject.org/en-US/package-maintainers/Package_Review_Process/#:~:text=You%20should%20make,as%20the%20resolution