[geofft]

That's still the norm! You're supposed to use the upstream tarball if one exists, and all of the tooling expects a tarball of some sort.

In fact there's an active discussion right now on debian-devel about maybe changing the norms to prefer VCS archives to upstream release tarballs (and rerunning any of the code generation steps like autoconf as part of the Debian build): https://lists.debian.org/debian-devel/2021/08/msg00133.html

... Also, the tooling not only expects a tarball, it expects every tarball with the same name to be bit-identical. So if foo 1.0 is already in Debian, you'd better not generate a slightly different foo-1.0.orig.tar.gz when you do a packaging update but you're still packaging version 1.0 of the upstream sources. In 2007 a tool called "pristine-tar" showed up to allow you to compute just enough information to regenerate the actual foo-1.0.orig.tar.gz from the foo 1.0 VCS tag and commit that delta onto a separate VCS branch. It's a pretty crucial but extremely finicky part of most workflows involving maintaining Debian packages via a VCS. And then it turns out that the author of pristine-tar actually was somewhat trying to "point out absurdities in the way things are done" (https://joeyh.name/blog/entry/twenty_years_of_free_software_...) and people just happily adopted the tool and made things more absurd.

[carreau]

I'm not using debian that much anymore, but I'd be happy to make any changes upstream to make it easier on debian.

When possible I try to have reproducible builds (https://reproducible-builds.org/) that respect SOURCE_DATE_EPOCH extracted from the commit datetime. At least for IPython I alway build twice to make sure the sha is identical.

I'd also be happy to have a way to signal to debian that there is a new release instead of having QA watch have to scan things regularly.

[southerntofu]

> I'd also be happy to have a way to signal to debian that there is a new release instead of having QA watch have to scan things regularly.

That would be great! Unfortunately the current forging model is very centralized, centered around the UX of private companies with their internal teams and little (if any) outside cooperation. That's why we need decentralized forging systems: https://staticadventures.netlib.re/blog/decentralized-forge/

There's an ongoing 5000€ bounty for implementing ForgeFed federation (based on ActivityPub) on top of Gitea, in case you know people familiar with golang/ActivityPub who'd like to help.

Also worth noting, i feel like there is room for experimenting with anti-authoritarian forging where you don't need upstream permission to receive webhooks (or other update notification). I've started experimenting with this but still pre-alpha quality: https://thunix.net/~southerntofu/forge/

> All of these CI/CD plateforms consider the repository itself should contain the tasks to be run, for example in a .gitlab-ci.yml file. This top-down deployment model is well suited to an organization controling the whole of its software supply chain, but is a severe restriction to 3rd party involvement, which mostly hinders volunteer-run projects.

> The forge suite adopts an opposite approach, where anyone can receive updates from remote repositories, and run the tasks they wish. This allows anyone within or without your projects to setup new test suites, benchmarks, and integrations. The applications are endless and should benefit your projects in many ways.

[jelmer]

You can actually notify the Janitor when there are new commits (and possibly tags indicating releases) in an upstream repository. The URL to target in the webhook is simply "https://janitor.debian.net/", and supported webhooks are those from GitLab, GitHub, Launchpad and Gitea.

Note that vcswatch doesn't actually scan upstream repositories, just Debian packaging repositories.

[grlass]

For those interested in reproducible builds, the gitian [1] project is a fairly simple VM which sets the up the necessary environment for doing this sort of thing.

The tooling and community around reproducible builds is growing all the time, and imo we should be insisting on it for things such as government apps.

[1] https://github.com/devrandom/gitian-builder

[rkeene2]

Building from tarball has many advantages over building from a VCS, especially a DVCS. The main one is that tarballs are serialized, hash-able, cache-able, mirror-able, checkable objects. Unlike a tag from which some serialized version must be synthesized (and therefore has multiple interpretations) and may require multiple round-trips to do from a remote resource.

In my Linux distribution, if something doesn't have a release tarball then I do something similar to "pristine-tar" to create the synthetic version that's stable over the decades (since I may need to rebuild the same software 10 years into the future). This is done through an HTTP-based service so I can fetch the result as if it were a tarball, and use all of the caching (by hash, see [0])as a result.

Release tarballs are VASTLY preferred for this reason.

Languages that try to "help" by circumventing this -- making reproducible builds into the future difficult -- have special helpers which go and fetch the resources (again, as serialized, checkable, hash-able objects) and make them available.

Some projects also attempt to download things from the Internet during the "build" phase of the project, so I created a tool to drop network access during that phase as well [1].

[0] https://hashcache.rkeene.org/ [1] https://chiselapp.com/user/rkeene/repository/bash-drop-netwo...

[account42]

Debians's view of the package source being a fork of the original source is definitely a bit odd. Most other packaging format see the original tarball as its own thing and then provide a recipe to build that tarball.