https://bugzilla.redhat.com/show_bug.cgi?id=2049400
--- Comment #16 from Dominik Wombacher <dominik(a)wombacher.cc> ---
(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?
--
You are receiving this mail because:
You are always notified about changes to this product and component
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2049400
Report this comment as SPAM:
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=rep...