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

vim-command-t upload errors



I'm trying & failing to manage to upload a new version of vim-command-t.

Starting from a clean slate:

    $ dput --force -d mentors ../vim-command-t_5.0.5-1_source.changes
    [...]
    [DEBUG] 1663751661.771559: (initialize) Logging into mentors.debian.net as anonymous
    [DEBUG] 1663751662.005920: (initialize) Enable PASV mode
    [DEBUG] 1663751662.006143: (initialize) Change directory to /pub/UploadQueue/
    Uploading vim-command-t_5.0.5-1.dsc
    [INFO] 1663751662.048132: (invoke_dput) Uploading vim-command-t_5.0.5-1.dsc
    Uploading vim-command-t_5.0.5.orig.tar.gz
    [INFO] 1663751662.248703: (invoke_dput) Uploading vim-command-t_5.0.5.orig.tar.gz
    cannot read from timed out object
    [CRITICAL] 1663751672.420859: (<module>) cannot read from timed out object

It looks like the connection's being closed during the transfer; the
original file is about 84 KiB but the file left in the upload queue is
only 14500 bytes:

    lftp mentors.debian.net:/pub/UploadQueue> ls
    -rw-------    1 1010     110         13932 Sep 21 08:03 vim-command-t-dbgsym_5.0.5-1_amd64.deb
    -rw-------    1 1010     110          1351 Sep 21 09:14 vim-command-t_5.0.5-1.dsc
    -rw-------    1 1010     110          6979 Sep 21 08:06 vim-command-t_5.0.5-1_amd64.buildinfo
    -rw-------    1 1010     110         14500 Sep 21 08:06 vim-command-t_5.0.5-1_amd64.deb
    -rw-------    1 1010     110         14500 Sep 21 09:14 vim-command-t_5.0.5.orig.tar.gz

Ignore the older files left behind by a previous upload attempt that
incorrectly included binary package. Although it's interesting that the
.deb and the .orig.tar.gz were both truncated to the same size...

In case anyone else runs into this problem, the solution is to re-run
dput with the --force option; it will skip uploading any files that
exist in the remote queue, and continue on to upload subsequent files
including the .changes file. Then queue processing will send out a
REJECT and delete the files.

While composing the above I did a bit of testing. I found that uploading
a 1 MiB file with lftp fails:

    lftp mentors.debian.net:/pub/UploadQueue> put /tmp/1MiBtest -o 1MiBtest.3
    ---> TYPE I
    <--- 200 Switching to Binary mode.
    ---> PASV
    <--- 227 Entering Passive Mode (185,22,221,46,55,235)
    ---- Connecting data socket to (185.22.221.46) port 14315
    ---- Data connection established
    ---> STOR 1MiBtest.3
    <--- 150 Ok to send data.
    **** data-socket: Connection reset by peer

    lftp mentors.debian.net:/pub/UploadQueue> ls 1MiBtest.3
    -rw-------    1 1010     110         14500 Sep 21 09:36 1MiBtest.3

... and the result is that the upload file is truncated to the same
length.

I also discovered that I was uploading my packages with dput-ng. After I
removed it and installed dput:

    $ dput -f mentors   ../vim-command-t_5.0.5-1_source.changes
    Checking signature on .changes
    gpg: ../vim-command-t_5.0.5-1_source.changes: Valid signature from 4E11A28B8650188A
    Checking signature on .dsc
    gpg: ../vim-command-t_5.0.5-1.dsc: Valid signature from 4E11A28B8650188A
    Uploading to mentors (via ftp to mentors.debian.net):
      Uploading vim-command-t_5.0.5-1.dsc: done.
      Uploading vim-command-t_5.0.5.orig.tar.gz: done.
      Uploading vim-command-t_5.0.5-1.debian.tar.xz: done.
      Uploading vim-command-t_5.0.5-1_source.buildinfo: done.
      Uploading vim-command-t_5.0.5-1_source.changes: done.
    Successfully uploaded packages.

It works!

dput-ng's error handling could certainly do with some improvement ... it
should (IMO) have continued on to upload the .changes file so that the
queue could REJCT the upload & delete the partial files. As for why
dput-ng and lftp both have trouble uploading to the server, but dput
does not, I've no idea...

-- 
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9


Reply to: