[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

udeb source inconsistencies in sarge

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
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.
	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

Reply to: