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

debian/patches review



Hi,

I checked at debian/patches/*, and how these patches should be handled
after applying the latest 2-2-branch glibc-cvs.dpatch.
Please review my check. If it's fine to include this in our cvs,
then I put it on debian/patches/0status. It's ok?
IMHO in -14 or -15, we update glibc-cvs.dpatch, then simply removed 
'remove' status files from 0list.

	Filename.dpatch
		2.2 CVS:	2.2 cvs has it.
		2.3 CVS:	2.3 cvs has it.
		Comment:	comment about it.
		Status:		see below.
	
	Status type is
		debian specific: Debian specific file.
		remove:		 It can be removed if we include glibc-cvs latest patch.
		already removed: It was already removed to apply, but exists.
		keep in 2.2.x:	 It's already in 2.2.9x branch, so during 2.2.x we keep applying.
		keep:		 Some reason exist to keep applying.
		discussion:	 We may need discussion.
		merge:		 I hope this patch should be send to upstream.
				 Before merge, we keep applying it.
		rewrite:	 We need rewrite patch.
		unknown:	 unknown

glibc-cvs.dpatch	
	2.2 CVS:	up to date 2002-08-07 or later.
	2.3 CVS:	-
	Comment:	the latest glibc-2-2-branch 
	Status:		debian specific.

template.dpatch
	2.2 CVS:	-
	2.3 CVS:	-
	Comment:	Debian specific template file.
	Status:		debian specific.

glibcbug.dpatch
	2.2 CVS:	-
	2.3 CVS:	-
	Comment:	Debian specific.
	Status:		debian specific.

xdr-array-security.dpatch
	2.2 CVS:	already in.
	2.3 CVS:	already in.
	Comment:	will be removed after -13.
	Status:		remove

glibc-openoffice-fixes.dpatch
	2.2 CVS:	already in
	2.3 CVS:	already in
	Comment:	will be removed after -13.
	Status:		remove

ia64-strncpy.dpatch
	2.2 CVS:	already in
	2.3 CVS:	already in
	Comment:	will be removed after -13.
	Status:		remove

syserrlist.dpatch
	2.2 CVS:	already in
	2.3 CVS:	already in
	Comment:	will be removed after -13.
	Status:		remove

pthread_create-manpage.dpatch
	2.2 CVS:	already in
	2.3 CVS:	already in
	Comment:	will be removed after -13.
	Status:		remove

resolv-nss_dns.dpatch
	2.2 CVS:	already in
	2.3 CVS:	already in
	Comment:	will be removed after -13.
	Status:		remove

sparc-misc.dpatch
	2.2 CVS:	already in
	2.3 CVS:	already in
	Comment:	will be removed after -13.
	Status:		remove

mathpatch.dpatch
	2.2 CVS:	already in
	2.3 CVS:	already in
	Comment:	will be removed after -13.
	Status:		remove

hurd-ioperms.dpatch
	2.2 CVS:	already in
	2.3 CVS:	already in
	Comment:	will be removed after -13.
	Status:		remove

hurd-lfs64.dpatch
	2.2 CVS:	already in
	2.3 CVS:	already in
	Comment:	will be removed after -13.
	Status:		remove

hurd-update.dpatch
	2.2 CVS:	already in
	2.3 CVS:	already in
	Comment:	will be removed after -13.
	Status:		remove

locales-de_CH.dpatch
	2.2 CVS:	already in
	2.3 CVS:	already in
	Comment:	will be removed after -13 (and it's my miss patch).
	Status:		remove

string2-pointer-arith.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	I tested sample programs (compiled with gcc-2.95, 3.0,
			3.1) stated in #45824, #44491, #44697, but I can't
			reproduce this problem without this patch.
			More test is needed but IMHO it can be removed after
			-13.
	Status:		remove

glibc22-s390-resource.dpatch
	2.2 CVS:	not in
	2.3 CVS:	already in
	Comment:	we keep applying this patch until moving to 2.2.9x.
	Status:		keep in 2.2.x

gmon-start.dpatch
	2.2 CVS:	not in
	2.3 CVS:	already in
	Comment:	we keep applying this patch until moving to 2.2.9x.
	Status:		keep in 2.2.x

db1-addon-enabler.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	db1 addon enabling patch. keep applying it.
	Status:		keep

glibc22-getaddrinfo.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	BenC and others already discussed about this patch 
			around 2001-11-24 on libc-alpha, and the result was
			Ulrich rejected this patch and he would rewrite
			resolver code. However it has not been resolved yet...
			We keep applying this patch for the moment.
	Status:		keep

ip6-fix.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	BenC posted about this issue around 2002-02-05 on
			libc-alpha, but no responce. arpa -> int is useful so
			we keep applying this patch for the moment.
	Status:		keep

glibc22-getdents-fix.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	It was discussed, but it's not applied (See #86877).
			we keep applying this patch for the moment.
	Status:		keep

fhs-linux-paths.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	This patch modifies pathname /var/db -> /var/lib/misc,
			following FHS. If RPM distributions use it,
			then it's debian specific currently.
			we keep applying this patch for the moment.
	Status:		keep

glibc22-locales.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	This patch is borrowed from SuSE. It's fine to
			merge within upstream, but I doubt all locales are
			checked or not.
			We keep applying this patch for the moment.
	Status:		keep

glibc2.2.6-nice.dpatch
	2.2 CVS:	-
	2.3 CVS:	-
	Comment:	It's already commented out. BenC?
	Status:		already removed

sparc64-got-fix.dpatch
	2.2 CVS:	-
	2.3 CVS:	-
	Comment:	It's already commented out. BenC?
	Status:		already removed

locales-stuff.dpatch
	2.2 CVS:	partially in
	2.3 CVS:	partially in
	Comment:	de_CH part is already in, ld-collate and locale.alias
			are not in. ld-collate should be sent to upstream,
			but locale.alias is difficult to handle because 
			Russian regional specific.
	Status:		rewrite

glibc22-misc.dpatch
	2.2 CVS:	not in?
	2.3 CVS:	not in?
	Comment:	At the first, we need to separate this file
			into appropriate patches.
			es_AR patch should be sent to upstream (#108373).
	Status:		rewrite

glibc22-eo_EO.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	I concern that EO is valid name or appropriate
			regional name in ISO-3166. IMHO regional name EO
			should be dropped. Yes, "eo" locale name is more
			appropriate. We may need to discuss with people at
			debian-esperanto@lists.debian.org . 
	Status:		discussion

glibc22-hppa-unwind.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	After checking it's ok or not, then submit to upstream
			if it's correct. This patch is applied only kernel
			version lower checking.
	Status:		merge

glibc22-m68k-compat.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	Should be merged within upstream if it's ok.
	Status:		merge

glibc22-m68k-fpic.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	Should be merged within upstream if it's ok.
	Status:		merge

glibc22-hppa-tests.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	IMHO, It's fine. It should be merged into upstream
			(#137513).
	Status:		merge

hppa-data-start.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	According to #133666, it's needed for hppa.
			I also think this symbol is lack, so should be send to
			upstream.
	Status:		merge

ia64-reloc-none.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	According to #135314 and so on, it's needed and should
			be sent to upstream.
	Status:		merge

ldd.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	it's useful, so we should send to upstream.
			I want to know upstream author's opinion.
	Status:		merge

powerpc-sysconf.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	I think this patch is right, we should send it to
			upstream author.
	Status:		merge

various-lsb-fixes.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	The behavior of setpriority in XPG6 says as following, 
			so this patch should be sent to upstream, IMHO.
			I wonder why it's not in main source.
		17860 The default nice value is {NZERO}; lower nice values shall cause more favorable scheduling.
		17861 While the range of valid nice values is [0,{NZERO}*2-1], implementations may enforce more
		17862 restrictive limits. If value+{NZERO} is less than the system s lowest supported nice value,
		17863 setpriority ( ) shalls et the nice value to the lowest supported value; if value+{NZERO} is greater
		17864 than the system s highest supported nice value, setpriority ( ) shall set the nice value to the highest
		17865 supported value.
		17866 Only a process with appropriate privileges can lower its nice value.
		17867 PS|TPS Any processes or threads using SCHED_FIFO or SCHED_RR shall be unaffected by a call to
		17868 setpriority ( ). This is not considered an error. A process which subsequently reverts to
		17869 SCHED_OTHER need not have its priority affected by such a setpriority ( ) call.
	Status:		merge

arm-no-hwcap.dpatch
	2.2 CVS:	not in.
	2.3 CVS:	not in.
	Comment:	This patch only drops (HWCAP_ARM_HALF | HWCAP_ARM_FAST_MULT)
			from HWCAP_IMPORTANT.
			I couldn't understand why it was dropped. Ben?
	Status:		unknown

glibc22-hppa-pthreads.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	? Ben?
	Status:		unknown

glibc22-hppa-rela.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	? Ben?
	Status:		unknown

glibc22-nss-upgrade.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	? Ben?
	Status:		unknown

glibc22-ttyname-devfs.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	? I don't know it's ok or not.
	Status:		unknown

hurd-ldflags.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	Jeff?
	Status:		unknown

ia64-perf.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	? I don't know it's ok or not.
	Status:		unknown

manual-texinfo4.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	I don't know why it's changed... Debian specific ?
	Status:		unknown

nscd-security-fix.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	It seems it's debian specific patch, but IMHO,
			we should discussed with upstream author.
	Status:		unknown

sparc64-fixups.dpatch
	2.2 CVS:	not in
	2.3 CVS:	not in
	Comment:	I don't know about it. Why does elf/ldconfig.c have
			architecture specific ifdef? Ben?
	Status:		unknown


-- gotom



Reply to: