Some udebs have a newer version in sarge from their source package. This is a leftover from the bad old days when I didn't check source versions of udebs whose source didn't build debs; I'm more careful now. The significant ones are:
colo-udeb 1.14-1 vs colo 1.10-1
colo is frozen
tbm "would like it", but doubts we will let the new version in
Elmo, would it be possible to get the colo-udeb 1.10-1 back into
sarge?
dmsetup-udeb, libdevmapper1.00-udeb 2:1.00.19-4 vs devmapper 2:1.00.19-2
the new devmapper is blocked by kernel-patch-evms
I don't don't if we use these udebs at all.
Might be best to get the 2:1.00.19-4 version back into sarge.
e2fsprogs-udeb, libblkid1-udeb, libuuid1-udeb 1.35-8 vs e2fsprogs 1.35-6
e2fsprogs is frozen
It's possible that some of the fixes (like #271064) impact d-i.
Not sure what to do here.
eject-udeb 2.0.13deb-8 vs eject 2.0.13deb-7
eject is frozen
The change in -8 looks narrowly misses breaking d-i, which does
not use /media.
Best to revert eject-udeb to -7 if possible.
ntfstools-udeb 1.9.4-1 vs linux-ntfs 1.9.2-2
linux-ntfs is held from testing by #278303
I have not taken the time to comprehend that bug report, but
the new upstream version apparently has "lots of fixes", and has
been thuroughly (ish) tested with d-i by now. I think we should
work to get 1.9.2-2 into testing.
openssh-client-udeb, openssh-server-udeb 1:3.8.1p1-8.sarge.2 vs openssh
1:3.8.1p1-8.sarge.1
Up to kamion, but I say revert the udebs to sarge.1 unless openssh
is updated to sarge.2, if possible.
fdisk-udeb
Like its source util-linux, this has a different version for
s390 in unstable and testing than any other arch.
Other than the above, udebs in testing should all have sources of the
same version and be fully consistent by the next britney run.
--
see shy jo
signature.asc
Description: Digital signature
