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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)