On 17-Dec-2017, Alf Gaida wrote:
> If you call correct behaviour a design change you are right
You have not shown any of the existing behaviour to be incorrect; you
have acknowledged that it is correct. (That is unrelated to whether
different proposed behaviour might *also* be correct.)
Instead,
If you call correct behaviour a design change you are right, but thats
not my problem anymore, i have an eight year tradition running self
patched dput's.
Cheers Alf
Control: tags -1 - moreinfo
Control: severity -1 wishlist
Control: retitle -1 dput: Test ‘allowed_distributions’ earlier
On 16-Dec-2017, Alf Gaida wrote:
> On 16.12.2017 00:26, Ben Finney wrote:
> > I'm having difficulty figuring out what bug is being described
> > here.
> Thats easy, the test fo
With the patch the allowed_distributions will be tested first:
> % dput ftp-eu *changes
> Traceback (most recent call last):
> File "/usr/bin/dput", line 11, in
> load_entry_point('dput==1.0.1+nmu1', 'console_scripts', 'execute-dput')()
> File "/usr/share/dput/dput/dput.py", line 1020, i
So now a successful upload looks like:
% dput -d ftp-eu *changes
D: dput 1.0.1+nmu1
D: Login: agaida
D: Parsing Configuration File /etc/dput.cf
No such file or directory: /home/agaida/.dput.cf, skipping
D: Checking if a host was named on the command line.
D: Host ftp-eu found in config
D: modules_
On 16.12.2017 00:26, Ben Finney wrote:
> I'm having difficulty figuring out what bug is being described here.
Thats easy, the test for allowed_distributions is far to late in
verify_files. Trivial tests first - i must not check for content, files,
signatures or anything else if i can't upload beca
On 15-Dec-2017, Alf Gaida wrote:
> On 15.12.2017 21:04, Ben Finney wrote:
> > So I think you've demonstrated this is not anything to do with the
> > Distribution field.
>
> You are right, but that's not the point - and i have no real problems
> with the current behaviour - it only sucked the first
On 15.12.2017 21:04, Ben Finney wrote:
> So I think you've demonstrated this is not anything to do with the
> Distribution field.
You are right, but that's not the point - and i have no real problems
with the current behaviour - it only sucked the first time i noticed
that. It migth be that one ge
On 15-Dec-2017, Alf Gaida wrote:
> % dput -d ftp-eu qps_1.10.17-2_source.changes
> […]
> Checking signature on .changes
> gpg: /home/agaida/work/code/pkg-main/qps/qps_1.10.17-2_source.changes:
> error 58: gpgme_op_verify
> gpgme_op_verify: GPGME: No data
>
> > Can you send that upload control fi
On 15.12.2017 01:26, Ben Finney wrote:> Can you try the command with
only the one upload control file
> (‘foo.changes’, whatever that file is)? This will help narrow down
> what is causing the behaviour.
Now the same package released:
% dput -d ftp-eu qps_1.10.17-2_source.changes
D: dput 1.0.1
D
On 15.12.2017 01:26, Ben Finney wrote:
> Can you try the command with only the one upload control file
> (‘foo.changes’, whatever that file is)? This will help narrow down
> what is causing the behaviour.
% dput -d ftp-eu *changes
D: dput 1.0.1
D: Login: agaida
D: Parsing Configuration File /etc/
Control: tags -1 + moreinfo
On 14-Dec-2017, Alf Gaida wrote:
> % dput ftp-eu *changes
Can you try the command with only the one upload control file
(‘foo.changes’, whatever that file is)? This will help narrow down
what is causing the behaviour.
> Checking signature on .changes
Can you send th
Package: dput
Version: 1.0.1
Severity: normal
Hi,
current output:
% dput ftp-eu *changes
Checking signature on .changes
gpg:
/home/agaida/work/code/pkg-main/lxqt-qtplugin/lxqt-qtplugin_0.12.0-4_source.changes:
error 58: Invocation of gpgme_op_verify
Invocation of gpgme_op_verify: GPGME: No dat
13 matches
Mail list logo
