On 17278 March 1977, Ian Jackson wrote:
Sean, I think we should finish updating the design with these agreed
changes. Joerg, when we have done that, will you review it and make
sure we have properly captured what you think we've agreed ?
Sure.
--
bye, Joerg
Joerg Jaspert writes ("Re: t2u in the archive"):
> Honestly I think that sounds way more complicated than a "git ls-files
> something" based file and process, and binds us more tightly to actual
> git than ls-files does (one could easily have more fields in there, if
&
On 17277 March 1977, Ian Jackson wrote:
Firstly, you say a "shallow clone".
It is not straightforward to include *precisely* the set of commits
that are required to reproduce the output. The conversion might, in
principle, go arbitrarily far into the maintainer's packaging branch;
and, if th
Simon Josefsson writes:
> You can mitigate this by re-validating all commit hashes using a SHA1CD
> git implementation before trusting a git repository. I have not seen
> confirmation that 'git fsck' actually do that.
I convinced myself that it does. One of the things git fsck does is
recalcul
Matthias Urlichs writes:
> On 01.07.24 12:46, Aigars Mahinovs wrote:
>> Yes and no. See what the git tag actually contains and what the GPG
>> signature actually signs is just the one hash of the commit object.
>> This commit object then refers to the other files of the repo, but the
>> GPG signa
On 01.07.24 12:46, Aigars Mahinovs wrote:
Yes and no. See what the git tag actually contains and what the GPG
signature actually signs is just the one hash of the commit object.
This commit object then refers to the other files of the repo, but the
GPG signature does not directly sign those.
So
On Mon, 1 Jul 2024 at 11:33, Matthias Urlichs wrote:
>
> On 30.06.24 21:30, Aigars Mahinovs wrote:
>
> The Debian developer/maintainer creates a signed git tag that contains
> (in its message, presumably, to avoid adding new communication lines)
> the file listing of the git checkout at the point
Hi again. Thanks for the clarifications. Speaking personally I've
found your replies encouraging, and I'm cautiously optimistic that
this might be a workable approach. We'll keep working on a proper
response.
In the meantime, I have a couple of questions.
Joerg Jaspert writ
On 30.06.24 21:30, Aigars Mahinovs wrote:
The Debian developer/maintainer creates a signed git tag that contains
(in its message, presumably, to avoid adding new communication lines)
the file listing of the git checkout at the point of signing
(including file names, modes and short SHA checksum h
On 17276 March 1977, Aigars Mahinovs wrote:
The only suggestion I would have here would be to have the shallow git
clone on the t2u side have a variable depth that is selected so that
the commits in the resulting depth are sufficient for the source
package construction, like in case of a rebase
On 17276 March 1977, Russ Allbery wrote:
So, in short: A t2u uploaded source package should consist of
whatever
t2u produces (normal Debian source package) *plus* two additional
files.
The first file contains client side generated data, but to *not*
overburden the client, this *only* consist
On 30.06.24 19:28, Russ Allbery wrote:
Oh! Did I misunderstand Joerg's second point entirely? By "the tag that
t2u wants to upload," I assumed that meant the tag the uploader signed or,
in other words, the state of the tree*before* t2u started doing its work
that has the uploader signature att
On Sun, 30 Jun 2024 at 20:47, Scott Kitterman wrote:
>
> On Sunday, June 30, 2024 1:45:15 PM EDT Aigars Mahinovs wrote:
> > On Sun, 30 Jun 2024 at 19:28, Russ Allbery wrote:
> > > Aigars Mahinovs writes:
> > > > Correct me if I'm wrong, but I believe the intention is to have two
> > > > technica
Aigars Mahinovs writes:
> In contrast, having a tarball of the git state *before* t2u starts its
> work would provide a tarball that *can* be verified against the
> checksums from the first file. That will give you a clear data point -
> t2u started its work with the exactly the same workspace as
On Sunday, June 30, 2024 1:45:15 PM EDT Aigars Mahinovs wrote:
> On Sun, 30 Jun 2024 at 19:28, Russ Allbery wrote:
> > Aigars Mahinovs writes:
> > > Correct me if I'm wrong, but I believe the intention is to have two
> > > technically redundant data points saved into the archive:
> > >
> > > 1)
On Sun, 30 Jun 2024 at 19:28, Russ Allbery wrote:
>
> Aigars Mahinovs writes:
> > Correct me if I'm wrong, but I believe the intention is to have two
> > technically redundant data points saved into the archive:
>
> > 1) checksums of the contents of the shallow copy git tree in the
> > maintainer
Aigars Mahinovs writes:
> On Sun, 30 Jun 2024 at 17:58, Russ Allbery wrote:
>>> The second file consists of a shallow git clone of the repository for
>>> the tag that t2u wants to upload, put into an appropriately named
>>> tarball.
>> Just to double check, to make sure I'm not missing some sub
On Sun, 30 Jun 2024 at 17:58, Russ Allbery wrote:
> > The second file consists of a shallow git clone of the repository for
> > the tag that t2u wants to upload, put into an appropriately named
> > tarball.
>
> Just to double check, to make sure I'm not missing some subtlety, it's
> intentional th
Joerg, thanks for trying to work with us to find a way forward.
Russ Allbery writes ("Re: t2u in the archive"):
> Thank you very much for putting this together! I know how hard it is to
> coordinate a bunch of voices and turn them into something concrete. This
> is incre
Joerg Jaspert writes:
> Now, we have the following proposal on how to get t2u integrated. Note,
> we are not entirely happy with it and do not think this is the best way
> forward, but given the current situation, it is a way that gets things
> untangled, and then we see what the future will brin
On 17273 March 1977, Sean Whitton wrote:
The ftpmaster team have refused to trust uploads coming from the
tag2upload service. This GR is to override that decision.
took us a few days to discuss and get to a point, but hey, where is the
hurry anyways? It's not like we are time bound in impleme
21 matches
Mail list logo
