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
Attachment:
signature.asc
Description: Digital signature