Re: FYI: vte 0.56.2 + No more ftp tarballs


Thanks for bringing this up.

On Thu, 2019-04-25 at 17:08 +0200, Debarshi Ray via release-team wrote:
Hey Egmont,

Thanks for the heads up!

On Thu, Apr 25, 2019 at 11:59 AM Egmont Koblinger <egmont gmail com> wrote:
- VTE 0.56.2 was released ahead of schedule in order to fix a crash
(RH #1701590). Could you please update the Rawhide (F30) package? (F29
with VTE 0.54.x is unaffected.)

- VTE git master (0.57 series) switched to the meson build system and
dropped autotools. Since there are no longer any autogenerated files
to distribute, we will no longer manually create tarballs and upload
them to the static ftp/http download area. Instead, you should check
out particular tags from git, or download the autogenerated tarballs
from gitlab at
(gnome-terminal is likely to follow soon, I won't send a separate FYI,
you'll notice it when it happens.)

I guess I could live with downloading the autogenerated GitLab
tarballs for the purposes of building Fedora packages. I wonder if
this has a bearing on how the GNOME release team builds things to
prepare the upstream GNOME releases. I have CC'ed them.

First of all, I think this is certainty a freedom that we want
maintainers to have, avoiding steps and process just makes things

For the technical part of creating a GNOME release, I don't think we're
quite ready for that at the moment, but I it should not be too much
work to update the script which converts `gnome-build-meta` to be aware
of modules which don't release as tarballs here:

Also, I'm not familiar with how release notes for major GNOME releases
are currently created, but I *think* there is a NEWS file aggregation
script which is based on the uploaded tarballs, that should probably
receive some attention too.

However there are other concerns than just this.

  * I think our gitlab instance is not really an appropriate
    infrastructure for hosting releases; when compared to the ftp
    server which has mirrors to help balance the load.

    This might result in intense CI pipelines for builds of downstream
    distros running around the world, continuously trying to download
    our modules directly from our poor little gitlab instance.

  * If I understand correctly, I might be wrong, but I think gitlab
    creates tarballs on the fly instead of persisting them in

    I raise this because I don't know with certainty that gitlab
    tarball creation is reproducible (in the bit-for-bit sense).

    This could mean that an upgrade of our gitlab or it's
    dependencies, can potentially result in the same tarballs being
    offered up but no longer matching the checksums as before.

I wonder if we might prefer an approach where we automate the creation
of tarballs for modules who have decided to rid themselves of the
process of creating tarballs ?


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