Dear Maintainer,
Many a time I get messages like these :-

Delta is not present: cpp_4%3a4.9.1-5_4%3a4.9.2-2_amd64.debdelta
                                                               Delta
is not present: cpp-4.8_4.8.3-13_4.8.4-1_amd64.debdelta
Delta is not present: cpp-4.9_4.9.1-19_4.9.2-10_amd64.debdelta
Delta is not present: g++_4%3a4.9.1-5_4%3a4.9.2-2_amd64.debdelta
Delta is not present: g++-4.9_4.9.1-19_4.9.2-10_amd64.debdelta
Delta is not present: gcc_4%3a4.9.1-5_4%3a4.9.2-2_amd64.debdelta
Delta is not present: gcc-4.8_4.8.3-13_4.8.4-1_amd64.debdelta
Delta is not present: gcc-4.8-base_4.8.3-13_4.8.4-1_amd64.debdelta
Delta is not present: gcc-4.9_4.9.1-19_4.9.2-10_amd64.debdelta

If it had said the delta is big, it would have been ok, which would
have told me that debdelta tried to re-create the delta but failed.

When you get the 'Delta is not present' it doesn't tell you anything.
You do not know whether it is because whether the server has not done
a delta run and hence the delta is not present or something else. You
do know that the debdelta server is not down because otherwise you
would get something like this :-

 sudo debdelta-upgrade
Connection error (fatal):  : debdeltas.debian.net
Delta is not downloadable (timed out
None):http://debdeltas.debian.net/debian-deltas/pool/main/v/vim/vim-common_2%3a7.4.488-3_2%3a7.4.488-4_amd64.debdelta

Umm... Is it possible to know when was debdelta last run on the remote
server as well ? I ask as logs are not currently retrievable

http://debdelta.debian.net/run/ - sorry logs are currently unavailable

Looking forward to know more.

Hi all,
Spent some time today and was interesting to see the various outputs.
I am still not sure why it says 'Delta is not present' - I wish I
could get some more precise output/statement -

$ sudo debdelta-upgrade -vv
Recreated debs are saved in the directory /var/cache/apt/archives
  Patching thread started.
  Already downloaded:  libpython2.7 2.7.9-2
  Already downloaded:  libpython2.7-dev 2.7.9-2
  Already downloaded:  libpython2.7-minimal 2.7.9-2
  Already downloaded:  libpython2.7-stdlib 2.7.9-2
  Already downloaded:  python2.7 2.7.9-2
  Already downloaded:  python2.7-dev 2.7.9-2
  Looking for a delta for python2.7-doc from 2.7.8-11 to 2.7.9-2
  Opening connection to:  debdeltas.debian.net
Delta is not present: python2.7-doc_2.7.8-11_2.7.9-2_all.debdelta
  No deb-policy "u", no download of
http://ftp.debian.org/debian/pool/main/p/python2.7/python2.7-doc_2.7.9-2_all.deb
  Already downloaded:  python2.7-minimal 2.7.9-2
 Deltas: 0 present and 1 not,
 downloaded so far: time 0.73sec, size 0B, speed   0B/sec.
  Patching thread ended , bye bye.
Delta-upgrade statistics:
 downloaded deltas, size 0B time 0sec speed 0B/sec
 total resulting debs, size 0B time 2sec virtual speed 0B/sec

So as can be seen all the others have their deltas downloaded and
patched up and it's only this one which is remaining for one reason to
the other.

Il 07/03/2015 10:20, shirish शिरीष ha scritto:
one possible cause: debdelta will not created deltas for packages that
are too small; but I am not sure that this covers all cases...

a.

at bottom :-

Dear Andrea,
In the above case at least, the .deb package was about 4.1 MB
(compressed size).

See :-

[/var/cache/apt/archives] - [188]
└─[$] ll -h | grep python2.7-doc

[21:50:06]
-rw-r--r-- 1 root root  4.1M Mar  1 17:59 python2.7-doc_2.7.9-2_all.deb

I do understand that for small packages it doesn't do the diff. (the
ones which are 7KB or 8KB or something like that.)

It is very difficult to know why sometimes delta takes forever to
happen or doesn't happen and why sometimes it happens instantly (apart
from the size, for e.g. I waited for over 24 hrs. for the gcc deltas
to come but none of them came).

One case where there will be a failure is if the package used from
'experimental' suite or 'unstable' suite a new version comes in
'unstable' while your suite is 'testing'

 [/etc/apt] - [199]
└─[$] cat preferences

[21:56:00]
Package: *
Pin: release testing
Pin-Priority: 600

Package: *
Pin: release experimental
Pin-Priority: 1

Package: *
Pin: release unstable
Pin-Priority: 1

In such a case the user will never come to know that the package can't
be diffed because it's from a different suite altogether. AFAIK the
diffing works only when both the packages are from the same suite
'testing.old.version.1 < testing.new.version.2 = diff > 80 or
'unstable/sid.old.version.1 < testing.new.version.2 = diff > 80. (but
that too if your /etc/apt/sources.list uses unstable/sid as your repo.
and it's total sid repo.)

In the case where the package is from 'experimental.old.version.1 <
unstable.new.version.2 don't think we would have debdelta as this has
not been done and most of the time it might be a failure as well
(dunno) or 'experimental.old.version.1 < testing.new.version.2' where
again such diffs. wouldn't happen or lastly 'unstable.old.version.1 <
unstable/testing.new.version.2' .

While the experimental ones are clearly out of the picture, last
couple of corner scenarios may be something that can be worked with
assuming you have good enough hardware to run those permutations and
combinations and getting the deltas as well as enough bandwidth to
distribute them.

It would at the very least make an interesting read of what you think
of the above test-cases/scenarios and if there are any thoughts of
tackling them in the near future.

Looking forward to hear from you.