Debian 11 "Bullseye" packages

[mkuthan]

Could you provide packages for the latest Debian 11 distribution "Bullseye", please?
For architectures like for existing Debian 10 "buster" packages, e.g: Arm32v7, Arm32v8 and x86_64.

[dspruell]

I'm planning a Fluent Bit deployment to Bullseye too - is it required to wait for #4344 to land for the packages and repository information to deploy?

[patrick-stephens]

We actually updated things for #3753 so I'll take the changes to a new PR based on that.

[patrick-stephens]

What about raspian/bullseye @edsiper ?
Looks like there is no base image yet so will skip for now:

$docker pull resin/rpi-raspbian:bullseye
Error response from daemon: manifest for resin/rpi-raspbian:bullseye not found: manifest unknown: manifest unknown

Looking into it I think the images have been moved: https://hub.docker.com/r/resin/rpi-raspbian

This repository is deprecated. All resin base images are moved to new namespace "balenalib". Please check our docs(https://www.balena.io/docs) or new dockerhub namespace(https://hub.docker.com/u/balenalib/) for more details.

It looks like we should be using balenalib/rpi-raspbian as it is a Verified Image as well as balenalib/rpi-raspbian:bullseye existing.

[patrick-stephens]

#4476 should provide bullseye packages for the staging builds once merged. I'll make sure to raise an equivalent PR for the current process on the separate packaging repository too.

Note we only provide AMD/ARM64 builds for debian - raspbian has arm/v6 solely.

[patrick-stephens]

• Raise packaging repo PR as well

[dspruell]

Could I check in on this? Just noticing https://docs.fluentbit.io/manual/installation/linux/debian still has no mention of Bullseye, and a test of the configuration for the repo suggests it's not published yet.

# apt update
Err:1 https://packages.fluentbit.io/debian/bullseye bullseye Release           
  404  Not Found [IP: 139.178.85.103 443]
Reading package lists... Done         
E: The repository 'https://packages.fluentbit.io/debian/bullseye bullseye Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

I saw issue/PR closed but wasn't certain if other items were still pending. Cheers!

[patrick-stephens]

Yeah the packages are currently not officially released but they are being built and tested as part of the staging workflow. These should get published once we do the next major release.

[patrick-stephens]

It slightly relates to making the contribution guidance a bit clearer, i.e. something is merged does not mean it is immediately released. I tried to improve things on this PR here although that's more about people contributing PRs: https://github.com/fluent/fluent-bit/pull/4565/files

[dspruell]

This is interesting, thanks. I wonder if the concepts of release and packaging could be separated in this workflow. i.e., packages should always be built/published for the most recent release, regardless of ongoing development for the next release. Although the next major release is pending, packages would be available for the existing stable release for all supported platforms. In this case the release version's code has already been tested, and can be built and published for newly supported targets at any point prior to the next release.

I'm also curious to know if with fluent-bit, is a less versioned approach to distribution releases feasible? In other words, can a release be packaged as a unified build for all supported Debian versions (rather than requiring different packages for bullseye, buster and stretch)? Some projects appear to do this, although I realize it's not feasible in all cases; an example is UniFi:

https://help.ui.com/hc/en-us/articles/220066768-UniFi-Network-How-to-Install-and-Update-via-APT-on-Debian-or-Ubuntu

[patrick-stephens]

We do actually have a staging workflow that is basically doing this to push to a bucket/registry - packages/images are also built from master for a subset on every push but primarily for testing against in CI rather than making available externally. I think the concern with making these widely available is that they're not "supported" so testing is great to get any issues resolved before a new official release but they should not be used for production.

In an ideal world of course, all testing would verify everything for all possible use cases before it is pushed to master but we're not there yet (and it may not be possible). I think it was brought up at a recent community meeting to do a more regular cadence though on releases (although this may be less popular for some stricter compliance environments) which might be a good option to just push things and fix next release.

I'd gladly have anything that simplifies the packaging process so if you have a suggestion or ideally a PR feel free to ping me on here or via email (pat at calyptia.com). There's quite a few things to do on the backlog though and only limited time! 👍