On Mon, Apr 19, 2021 at 10:33:15AM -0700, Micheal Waltz wrote: > Followed the github PR this morning and saw gofeed was merged and > your email to the list about packaging the new version. I uploaded the new version to experimental[1] I also built amfora, it builds and I am able to locally install it and use as well. We are close to doing an upload, after you look at amfora once. [1]: https://tracker.debian.org/news/1239232/accepted-golang-github-mmcdole-gofeed-112-1exp0-source-into-experimental/ > I'm going to go through the commits since the versions used in Amfora > 1.8 to make sure there are no breaking changes, and then update the > debian/patch for Amfora to no longer use the forks. They are not using the forks in current state. AIUI, there is nothing to change at this point in patches - all that was needed was to change cview/cbin import paths that you did already > Once you've packaged > the newer version of gofeed I'll build Amfora again from 1.8 with the > patch and that should hopefully be it. > > If all goes well I'll ping you when the Amfora 1.8 is ready for review > and upload. A bunch of things that I need to convey: * amfora depends strictly on 1.1.2 version of gofeed and since we are in deep freeze now, a new upstream version of gofeed can not go to unstable at this point. Hence the reason I pushed it to experimental Now since amfora depends strictly on the version of gofeed in experimental (1.1.2), amfora can be uploaded to NEW, targeting experimental and not unstable at this point. Once bullseye is out, I will move gofeed and amfora to unstable. (whenever amfora is accepted into experimental) Hope that sounds OK to you. * Due to strict version dep, I made Build-Depends versioned and pushed to salsa[1] * In order to build for experimental, you need to add "--extra-repository='deb http://deb.debian.org/debian experimental main' --build-dep-resolver=aptitude" to sbuild. It will however take some time for amfora to land into experimental archive (a push to mirror happens every six hours starting 1:52 UTC) Till then you can do "--extra-repository='deb https://incoming.debian.org/debian-buildd buildd-unstable main' --build-dep-resolver=aptitude" to build it > Also talked some with Amfora upstream today and they are excited about > the PRs and Debian packaging. They did have one question about if Amfora > would get into buster-backports or just be in sid until it migrates to > testing. It will not get to buster-backports. It can however be pushed to bullseye-backports after a) bullseye is release (obviously :-)) b) amfora migrates to testing > What is the procedure on backporting a package (probably to > bullseye-backports since it's almost released). So you need to build amfora and all its deps with a clean, stable chroot and a DD who has been added to backports ACL will upload it for you. Praveen made a nice wiki for the procedure to do it, see this[2] For more info, look at backports.d.o website as well. > Is Amfora 1.8 a candidate for backports once it's all squared away and in > experimental/unstable? For a package to be backported, it has to be in testing. Once it gets to testing, definitely. But pushing to testing will take some extra work because all its dependencies need to migrate to testing first and for that we need to fix all dependencies, as an example progressbar fails its autopkgtests for non-x86 and someone will need to fix it. Also building all dependencies for stable, and pushing it to backports will also take a lot of effort. But for sure, it is doable. Please let me know if my answers are not clear. Probably I wrote stuff in not-so-clear way ;-) [1]: https://salsa.debian.org/go-team/packages/amfora/-/commit/703ec9445feb6ee230f6990783dc4ad9d223a589 [2]: https://salsa.debian.org/ruby-team/gitlab/-/wikis/buster-backports Kind Regards, Nilesh
Attachment:
signature.asc
Description: PGP signature