Hi Noah, On Mon, Oct 31, 2022 at 10:50:19PM -0700, Noah Meyerhans wrote: > On Tue, Oct 05, 2021 at 11:10:43PM -0600, Ross Vandegrift wrote: > > > awscli v2 remains quite difficult to package, but it seems that upstream > > > is looking to address this. See > > > https://github.com/aws/aws-cli/issues/6186 for details and tracking. > > > > Using the source dist poc from https://github.com/aws/aws-cli/pull/6352 I've > > made enough progress to get a packaged aws-cli v2 working. There's a lot > > more > > that needs to be done, but idea of the above linked PR could work for us. > > I'm > > going to document my findings here. > > So, only a year later, I've picked this up and made some additional > progress: > > I have no name!@b02f1db79f9e:/src$ aws --version > aws-cli/2.8.7 Python/3.10.8 Linux/6.0.0-2-amd64 source/x86_64.debian > prompt/off > I have no name!@b02f1db79f9e:/src$ dpkg -s awscli | grep Version > Version: 2.8.7-1
Great news! > > - some repos have tests disabled due to failing during builds. So far, I > > don't > > know if these are real failures, or if upstream's build method. > > I think I've got most of these fixed. 🤘 > > - copyright attribution for aws-lc is very hard. It's a fork of Google's > > BoringSSL, which is a fork of pre-3.0 OpenSSL. > > > > - That also means that aws-lc inherits the openssl gpl incompatibility. > > Here's the good news: We don't actually need aws-lc at all. awscli v2 > and its various dependencies (including s2n-tls) can build against > OpenSSL 3. 🤘 > > - the aws-cli2-temp repo is based on upstream, not our awscli repo. I was > > intentionally being sloppy to quickly get through a test. > > Same. I essentially Debianized the upstream v2 repo from scratch, > pulling in some of your packaging metadata as it made sense. Given that > v2 is developed on a different branch and by now differs quite > significantly from v1, a case could be made for introducing a new > awscli2 package as a new source package and retiring the original awscli > package. However, the debian package metadata isn't really all that > complex, so it may not actually be necessary. Is there any reason to have both versions available to install at once? > > - aws-lc and s2n-tls may be hard to maintain. Both are complicated, > > security > > critical crypto libraries. > > Fortunately, aws-lc isn't an issue. But s2n-tls remains one. Not sure > we're going to be able to do anything about that. The difficult thing > is that it's typically expected to be used as a statically linked > library, which means updates end up being tedious. Agreed, there's nothing we can do about it. But I think it's good news to be able to use OpenSSL and just have one highly security sensitive package. > I haven't pushed my changes anywhere, yet. Once I do, the remaining > tasks will be to any lintian issues or other obvious problems and get > these packages into NEW. I think they're in reasonably good shape, but > we don't have a lot of time before bookworm starts freezing, so I'd love > any help with these steps. I might have some time to help. Would it be useful to transfer my original repos to the cloud-team group? Ross
