• tag2upload: extending discussion; committing new reqs to git

    From Sean Whitton@21:1/5 to All on Mon Jul 1 15:00:01 2024
    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 -
  • From Sean Whitton@21:1/5 to All on Wed Jul 3 15:30:01 2024
    Hello,

    Joerg, here is the hopefully-final version.

    If you are happy with it then I will add
    "Acked-by: Joerg Jaspert <joerg@debian.org>"
    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 <spwhitton@spwhitton.name>
    Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
    ---
    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
    +=======================
  • From Sean Whitton@21:1/5 to Sean Whitton on Wed Jul 3 15:40:01 2024
    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)
  • From Joerg Jaspert@21:1/5 to Sean Whitton on Wed Jul 3 16:50:01 2024
    On 17279 March 1977, Sean Whitton wrote:

    If you are happy with it then I will add
    "Acked-by: Joerg Jaspert <joerg@debian.org>"
    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)
  • From Ian Jackson@21:1/5 to Joerg Jaspert on Wed Jul 3 18:00:02 2024
    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 <ijackson@chiark.greenend.org.uk> 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)
  • From Joerg Jaspert@21:1/5 to Ian Jackson on Wed Jul 3 22:30:02 2024
    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)
  • From Ian Jackson@21:1/5 to Joerg Jaspert on Thu Jul 4 01:00:01 2024
    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 <ijackson@chiark.greenend.org.uk> 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)
  • From Sean Whitton@21:1/5 to Joerg Jaspert on Thu Jul 4 04:20:01 2024
    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 <spwhitton@spwhitton.name>
    Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
    ---
    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
    +=======================
  • From Marc Haber@21:1/5 to Sean Whitton on Thu Jul 4 08:50:02 2024
    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)
  • From Joerg Jaspert@21:1/5 to Sean Whitton on Thu Jul 4 22:00:01 2024
    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)
  • From Ian Jackson@21:1/5 to Joerg Jaspert on Thu Jul 4 22:40:02 2024
    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 <ijackson@chiark.greenend.org.uk> 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)
  • From Joerg Jaspert@21:1/5 to Ian Jackson on Thu Jul 4 23:00:02 2024
    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)
  • From Richard Lewis@21:1/5 to Sean Whitton on Sat Jul 6 18:10:02 2024
    Sean Whitton <spwhitton@spwhitton.name> 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)