Hello,

Firstly, Andreas:

In the context of this productive discussion we're now having, I'd like
to ask you to use your DPL powers to increase the minimum and maximum discussion periods for this GR by one week each.
I believe that will be enough time to nail things down, such that I can withdraw my GR proposal with confidence that it's unneeded.

Secondly, Joerg:

Ian and I discussed it, and to make sure we are all on the same page, we propose that we edit our TAG2UPLOAD-DESIGN.txt to match what we think
you are asking for, and then you can tell us "yes, that's what we meant"
or "no, that misses the point".

Here is a first attempt at an update -- please review.

There are some cases where this differs from your proposal, which I've
marked with "NOT YET AGREED". We're discussing those in the other
thread, and haven't quite converged yet, but we decided to write them
into this draft because we're optimistic we'll converge soon.

-- 8< --
---
TAG2UPLOAD-DESIGN.txt | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)

diff --git a/TAG2UPLOAD-DESIGN.txt b/TAG2UPLOAD-DESIGN.txt
index 6dbfaec4..a227b32a 100644
--- a/TAG2UPLOAD-DESIGN.txt
+++ b/TAG2UPLOAD-DESIGN.txt
@@ -140,6 +140,9 @@ Not exposed via the git protocol, not even as a client.
target suite on the command line. Target host is the Builder.
(We use the existing dgit rpush signing oracle protocol.)

+ XXXX rpush protocol to be extended to include new .git.tar.xz
+ as described below
+
* Sends an email saying what it did.

* Reports the outcome success/failure and a summary line
@@ -231,6 +234,25 @@ binary build reproduction), or a suitable script, which can verify a
reproduction attempt. For now the src:dgit test suite will check that
the upload is reproducible if run again in the same environment.

+The upload will also contain a file SOURCE_VERSION.git.tar.xz which is a +compressed archive of the result of doing
+
+ % git clone -

Hello,

Joerg, here is the hopefully-final version.

If you are happy with it then I will add
"Acked-by: Joerg Jaspert <[email protected]>"
and then I will commit it, and send a message withdrawing my GR.

(Please say explicitly if you don't want me to use Acked-by like this,
but we generally use these kernel-style trailers in dgit.git.)

Thanks.

-- >8 --
Subject: [PATCH] Record tag2upload changes agreed with ftpmaster

The ftpmaster delegates agree that the design changes introduced by this
commit satisfy their requirements stated in
<https://lists.debian.org/debian-vote/2024/06/msg00602.html>.

They intend to configure dak to accept and trust uploads coming from the tag2upload service on the basis of us implementing these changes.

Signed-off-by: Sean Whitton <[email protected]>
Signed-off-by: Ian Jackson <[email protected]>
---
TAG2UPLOAD-DESIGN.txt | 54 ++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 53 insertions(+), 1 deletion(-)

diff --git a/TAG2UPLOAD-DESIGN.txt b/TAG2UPLOAD-DESIGN.txt
index 6dbfaec4..a985e580 100644
--- a/TAG2UPLOAD-DESIGN.txt
+++ b/TAG2UPLOAD-DESIGN.txt
@@ -138,7 +138,8 @@ Not exposed via the git protocol, not even as a client.

* Runs dgit rpush, specifying the package, version and
target suite on the command line. Target host is the Builder.
- (We use the existing dgit rpush signing oracle protocol.)
+ (We use the existing dgit rpush signing oracle protocol, except extended
+ to include the new SOURCE_VERSION.git.tar.xz described below.)

* Sends an email saying what it did.

@@ -231,6 +232,57 @@ binary build reproduction), or a suitable script, which can verify a
reproduction attempt. For now the src:dgit test suite will check that
the upload is reproducible if run again in the same environment.

+SOURCE_VERSION.git.tar.gz
+=======================

Hello,

On Wed 03 Jul 2024 at 09:25pm +08, Sean Whitton wrote:

+SOURCE_VERSION.git.tar.gz
+=========================
+

This is a typo, and should be .tar.xz.

--
Sean Whitton

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17279 March 1977, Sean Whitton wrote:

If you are happy with it then I will add
"Acked-by: Joerg Jaspert <[email protected]>"
and then I will commit it, and send a message withdrawing my GR.

(Please say explicitly if you don't want me to use Acked-by like this,
but we generally use these kernel-style trailers in dgit.git.)

Works for me.

+ It is jointly sufficient, together with the orig.tar, to
(re)produce
+ the source package.

This does read quite funny to me. "To reproduce what t2u did and get to
the source package, you need this SOURCE_VERSION tarball plus the orig
tarball that t2u generated in the step you want to reproduce".

I think I see where it comes from (space savings), but wonder if that is
a good thing here. Or what do i miss?

--
bye, Joerg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Joerg Jaspert writes ("Re: tag2upload: extending discussion; committing new reqs to git"):

+ It is jointly sufficient, together with the orig.tar, to
(re)produce
+ the source package.

This does read quite funny to me. "To reproduce what t2u did and get to
the source package, you need this SOURCE_VERSION tarball plus the orig tarball that t2u generated in the step you want to reproduce".

I think I see where it comes from (space savings), but wonder if that is
a good thing here. Or what do i miss?

This was wording from me. And you are right, there is a mistake here.

There are two cases:

* The .orig was in the archive already, in which case will need it to
reproduce the t2u output. Ie, in this case it's an input.

* The .orig was *not* in the archive already. In which case t2u made
it and (obviously) you don't need to provide it. It's an output.

How about:

(Together with any existing .orig.tar which was already
present in the archive.)

?

Ian.

--
Ian Jackson <[email protected]> These opinions are my own.

Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17279 March 1977, Ian Jackson wrote:

This does read quite funny to me. "To reproduce what t2u did and get
to
the source package, you need this SOURCE_VERSION tarball plus the
orig
tarball that t2u generated in the step you want to reproduce".

I think I see where it comes from (space savings), but wonder if that
is
a good thing here. Or what do i miss?

This was wording from me. And you are right, there is a mistake here.

There are two cases:

* The .orig was in the archive already, in which case will need it to
reproduce the t2u output. Ie, in this case it's an input.

* The .orig was *not* in the archive already. In which case t2u made
it and (obviously) you don't need to provide it. It's an output.

How about:

(Together with any existing .orig.tar which was already
present in the archive.)

For uploads not including the full source the already existing source
tarball present in the archive.

Or something similar. That is, just a bit more focus on the point that
this is for "following" uploads.

--
bye, Joerg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Joerg Jaspert writes ("Re: tag2upload: extending discussion; committing new reqs to git"):

For uploads not including the full source the already existing source
tarball present in the archive.

Yes, this seems right to me.

Sean, can you integrate this into the patch?

Thanks,
Ian.

--
Ian Jackson <[email protected]> These opinions are my own.

Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On Wed 03 Jul 2024 at 10:23pm +02, Joerg Jaspert wrote:

For uploads not including the full source the already existing source
tarball present in the archive.

Or something similar. That is, just a bit more focus on the point that
this is for "following" uploads.

Thanks for the feedback on this. Here is a revised diff.

-- >8 --
Subject: [PATCH] Record tag2upload changes agreed with ftpmaster

The ftpmaster delegates agree that the design changes introduced by this
commit satisfy their requirements stated in
<https://lists.debian.org/debian-vote/2024/06/msg00602.html>.

They intend to configure dak to accept and trust uploads coming from the tag2upload service on the basis of us implementing these changes.

Signed-off-by: Sean Whitton <[email protected]>
Signed-off-by: Ian Jackson <[email protected]>
---
TAG2UPLOAD-DESIGN.txt | 56 ++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 55 insertions(+), 1 deletion(-)

diff --git a/TAG2UPLOAD-DESIGN.txt b/TAG2UPLOAD-DESIGN.txt
index 6dbfaec4..a6fdf199 100644
--- a/TAG2UPLOAD-DESIGN.txt
+++ b/TAG2UPLOAD-DESIGN.txt
@@ -138,7 +138,8 @@ Not exposed via the git protocol, not even as a client.

* Runs dgit rpush, specifying the package, version and
target suite on the command line. Target host is the Builder.
- (We use the existing dgit rpush signing oracle protocol.)
+ (We use the existing dgit rpush signing oracle protocol, except extended
+ to include the new SOURCE_VERSION.git.tar.xz described below.)

* Sends an email saying what it did.

@@ -231,6 +232,59 @@ binary build reproduction), or a suitable script, which can verify a
reproduction attempt. For now the src:dgit test suite will check that
the upload is reproducible if run again in the same environment.

+SOURCE_VERSION.git.tar.xz
+=======================

On Wed, Jul 03, 2024 at 09:34:56PM +0800, Sean Whitton wrote:

On Wed 03 Jul 2024 at 09:25pm +08, Sean Whitton wrote:

+SOURCE_VERSION.git.tar.gz
+=========================
+

This is a typo, and should be .tar.xz.

We really should have technology independent language for this. We're
never going to be in a state where all our documents properly and
consistently reflect the preferred compression algorithm of the year.

Greetings
Marc


-- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17280 March 1977, Sean Whitton wrote:

Thanks for the feedback on this. Here is a revised diff.

Works for me now.

--
bye, Joerg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Joerg Jaspert writes ("Re: tag2upload: extending discussion; committing new reqs to git"):

On 17280 March 1977, Sean Whitton wrote:

Thanks for the feedback on this. Here is a revised diff.

Works for me now.

OK, great! Thanks for all the work and review and suggestions, and
for the compromise.

I've applied the patch, here:

https://salsa.debian.org/dgit-team/dgit/-/blob/dfdb3ac719e6f6d60535567753afb2be97ca4b04/TAG2UPLOAD-DESIGN.txt

(version without JS:)

https://salsa.debian.org/dgit-team/dgit/-/raw/dfdb3ac719e6f6d60535567753afb2be97ca4b04/TAG2UPLOAD-DESIGN.txt

Just to be sure: we think you're saying on behalf of ftpmaster, that
this design is OK with the team. Can you please confirm?

We can then go and implement the missing parts. I am really looking
forward to writing the code - and to getting bug reports!

Thanks,
Ian.

--
Ian Jackson <[email protected]> These opinions are my own.

Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17280 March 1977, Ian Jackson wrote:

Just to be sure: we think you're saying on behalf of ftpmaster, that
this design is OK with the team. Can you please confirm?

This one works for us, yes.

--
bye, Joerg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sean Whitton <[email protected]> writes:

diff --git a/TAG2UPLOAD-DESIGN.txt b/TAG2UPLOAD-DESIGN.txt
index 6dbfaec4..a6fdf199 100644
--- a/TAG2UPLOAD-DESIGN.txt
+++ b/TAG2UPLOAD-DESIGN.txt
@@ -138,7 +138,8 @@ Not exposed via the git protocol, not even as a client.

+The .changes will also contain a file SOURCE_VERSION.git.tar.xz which is
+a compressed git repository with the following properties:
+

+ * These reproductions are up to equality of file names and contents
+ -- timestamps of files may differ.

I think this use of "up to" is not what you meant to write -- pseudo-mathematicians generally use this to mean "excluding" (or
"disregarding" is suggested at [1] ), so "up to equality of file names
and contents" would suggest file names and contents *can* be changed at
will -- i think you just mean that "timestamps of files may differ".

[1] https://math.stackexchange.com/questions/3647362/meaning-of-up-to -
see the first answer

sorry for nitpicking, but i assume it's helpful to get this precise

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)