[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packaging Amfora and dependencies

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

[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

* 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,

Attachment: signature.asc
Description: PGP signature

Reply to: