Bug#297769: patch
At Mon, 11 Apr 2005 18:19:57 -0700,
Steve Langasek wrote:
Given that other packages may in the future begin to depend on this
interface, I think this should really just be done as a shlibdeps bump.
I investigated this problem, and finally I decided to bump up shlib
vers because (1) it seems it's harmless with my some tests, (2) we
can't anticipate which packages use sched_{set,get}affinity, even if
we have lintian labs (ex: fakeroot does not sched_*).
Regards,
-- gotom
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297769: patch
At Fri, 8 Apr 2005 19:13:49 -0400,
Daniel Jacobowitz wrote:
On Sat, Apr 09, 2005 at 12:46:24AM +0900, GOTO Masanori wrote:
At Fri, 8 Apr 2005 15:31:56 +0200,
Bastian Blank wrote:
Also GLIBC_PRIVATE is only used by glibc itself, so the only source of
problems may the different glibc packages. But I currently see nothing
which may really cause problems here as ld.so is not effected. (See this
as a small part of the upgrade to 2.3.4, with the exception that you
don't break the compatiblity between ld.so and libc.so.6.)
Yes, exactly, thinking about upgrade to 2.3.4, it should not make a
problem.
I'm rathar a bit nervous of supporting this special situation (ex:
distro compatibility and so on) because -21 should be the last call
for sarge stuff...
Could you explain what it is you're worried about? We absolutely
ought to have this patch...
OK, I put the patch. Currently I found the problem about schedutils.
Once schedutils `taskset' command uses new sched_getaffinity and
sched_setaffinity interface (which has GLIBC_2.3.4), schedutils has to
depend on glibc = 2.3.2.ds1-21.
I'm currently searching how to set Depends: libc6 (= 2.3.2.ds1-21) or
libc6.1 (= 2.3.2.ds1-21) [ia64, alpha] for schedutils.
BTW, if we change the library exported symbol version, GLIBC_2.3.4, we
should always bump up our shlibs from 2.3.2.ds1-4 to 2.3.2.ds1-21.
However, such change affects almost all binaries. Is this acceptable?
IMHO, changing shlibs affects a lot of packages, so I would like to
take the workaround fix - schedutils and fakeroot just have special
Depends: = 2.3.2.ds1-21, because I guess sched_{get,set}affinity is
not used widely.
Regards,
-- gotom
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297769: patch
I forgot to say that if we use schedutils compiled with glibc
2.3.2.ds1-21 (using new sched_{get,set}affinity) + glibc 2.3.2.ds1-21
runtime libraries:
bash-2.05b# ./taskset
taskset version 1.3.4
...
But if we use schedutils compiled with glibc 2.3.2.ds1-21 + glibc
2.3.2.ds1-20 runtime libraries:
./taskset: /lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.3.4' not
found (required by ./taskset)
Because 2.3.2.ds1-20 does not have symbol version GLIBC_2.3.4.
Regards,
-- gotom
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297769: patch
On Tue, Apr 12, 2005 at 01:30:08AM +0900, GOTO Masanori wrote:
OK, I put the patch. Currently I found the problem about schedutils.
Once schedutils `taskset' command uses new sched_getaffinity and
sched_setaffinity interface (which has GLIBC_2.3.4), schedutils has to
depend on glibc = 2.3.2.ds1-21.
I'm currently searching how to set Depends: libc6 (= 2.3.2.ds1-21) or
libc6.1 (= 2.3.2.ds1-21) [ia64, alpha] for schedutils.
BTW, if we change the library exported symbol version, GLIBC_2.3.4, we
should always bump up our shlibs from 2.3.2.ds1-4 to 2.3.2.ds1-21.
However, such change affects almost all binaries. Is this acceptable?
IMHO, changing shlibs affects a lot of packages, so I would like to
take the workaround fix - schedutils and fakeroot just have special
Depends: = 2.3.2.ds1-21, because I guess sched_{get,set}affinity is
not used widely.
I think that we should just be bumping the shlibdeps; the release team
has already agreed that we need a glibc update for sarge.
In any case, the best way to do what you want in schedutils mightb be:
Depends: ${shlib:Depends}
Conflicts: libc6 (= 2.3.2.ds1-21), libc6.1 (= 2.3.2.ds1-21)
I think that'll work... but make sure apt can cope.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297769: patch
At Mon, 11 Apr 2005 12:35:29 -0400,
Daniel Jacobowitz wrote:
On Tue, Apr 12, 2005 at 01:30:08AM +0900, GOTO Masanori wrote:
OK, I put the patch. Currently I found the problem about schedutils.
Once schedutils `taskset' command uses new sched_getaffinity and
sched_setaffinity interface (which has GLIBC_2.3.4), schedutils has to
depend on glibc = 2.3.2.ds1-21.
I'm currently searching how to set Depends: libc6 (= 2.3.2.ds1-21) or
libc6.1 (= 2.3.2.ds1-21) [ia64, alpha] for schedutils.
BTW, if we change the library exported symbol version, GLIBC_2.3.4, we
should always bump up our shlibs from 2.3.2.ds1-4 to 2.3.2.ds1-21.
However, such change affects almost all binaries. Is this acceptable?
IMHO, changing shlibs affects a lot of packages, so I would like to
take the workaround fix - schedutils and fakeroot just have special
Depends: = 2.3.2.ds1-21, because I guess sched_{get,set}affinity is
not used widely.
I think that we should just be bumping the shlibdeps; the release team
has already agreed that we need a glibc update for sarge.
I think it's not same issue; bumping shlib version is not glibc bug
fix update.
In any case, the best way to do what you want in schedutils mightb be:
Depends: ${shlib:Depends}
Back to the original suggestion by David Mosberger was: the recent
sources (ex: Lmbench3) use new sched_{set,get}affinity syscalls, so
such programs will need to consider debian's old syscalls interfaces
in future.
Thus, this change does _NOT_ affect any current debian archives.
These old syscalls are used by only fakeroot and schedutils, and the
current fakeroot/schedutils .debs do not use new syscalls. When we
think only for debian, this change is not useful at all. In other
words, this modification focuses on only unknown unbounded NON-DEBIAN
sources or binaries (even if old interfaces are incorrect).
I concern to bump up shlib version - I don't know why I'm worrying,
but at least when we discussed about this issue, we didn't anticipate
that adding new symbols makes additional consideration - I still think
bumping up shlib version needs incidental affection and it's large
change at this time.
Conflicts: libc6 (= 2.3.2.ds1-21), libc6.1 (= 2.3.2.ds1-21)
I think that'll work... but make sure apt can cope.
We don't need any additional Conflicts because:
(1) the current schedutils has Depends: libc6 (= 2.3.2.ds1-4), and
it works finely with libc6 2.3.2.ds1-21 because -21 also has old
GLIBC_2.3.3 sched_{get,set}affinity symbols.
(2) new schedutils has Depends: libc6 (= 2.3.2.ds1-21) and
Build-Depends: libc6 (= 2.3.2.ds1-21). It needs new libc6 -21,
and it uses GLIBC_2.3.4 sched_{get,set}affinity.
So I would like to change as follows:
(1) glibc -21 has new sched_{get,set}affinity at last.
(2) New schedutils should be released until sarge release with the
attached patch.
(3) fakeroot does not need to be modified because it does not have
any explicit sched_*affinity. It seems schedutils is the only
affected package.
I put new -21 and schedutils at:
http://www.gotom.jp/~gotom/debian/glibc/2.3.2.ds1-21_i386.sched/
Steve, how about this thought? Do you want to bump up glibc shlib
version rathar than my small hack? I would like to hear your opinion
from the RM point of view. Any comments are welcome.
--- schedutils-1.3.4/taskset.c.gotom2005-04-12 00:13:07.0 +0900
+++ schedutils-1.3.4/taskset.c 2005-04-12 00:14:04.0 +0900
@@ -130,7 +130,7 @@
if (pid) {
unsigned long mask = 0;
- if (sched_getaffinity(pid, cur_mask) 0) {
+ if (sched_getaffinity(pid, sizeof (cur_mask), cur_mask) 0) {
perror(sched_getaffinity);
fprintf(stderr, failed to get pid %d's affinity\n,
pid);
@@ -152,13 +152,13 @@
ulong_to_cpu_set(the_mask, new_mask);
- if (sched_setaffinity(pid, new_mask)) {
+ if (sched_setaffinity(pid, sizeof (new_mask), new_mask)) {
perror(sched_setaffinity);
fprintf(stderr, failed to set pid %d's affinity.\n, pid);
return 1;
}
- if (sched_getaffinity(pid, cur_mask) 0) {
+ if (sched_getaffinity(pid, sizeof (cur_mask), cur_mask) 0) {
perror(sched_setaffinity);
fprintf(stderr, failed to get pid %d's affinity.\n, pid);
return 1;
--- schedutils-1.3.4/debian/control.gotom 2005-04-11 15:33:36.0
+
+++ schedutils-1.3.4/debian/control 2005-04-11 23:54:06.0 +
@@ -2,12 +2,12 @@
Section: utils
Priority: optional
Maintainer: Guus Sliepen [EMAIL PROTECTED]
-Build-Depends: debhelper ( 3.0.0), libc6-dev (= 2.3) [!ia64 !alpha],
libc6.1-dev (= 2.3) [ia64 alpha]
+Build-Depends: debhelper ( 3.0.0), libc6-dev (= 2.3.2.ds1-21) [!ia64
!alpha], libc6.1-dev (= 2.3.2.ds1-21) [ia64 alpha]
Bug#297769: patch
On Mon, Apr 11, 2005 at 12:35:29PM -0400, Daniel Jacobowitz wrote:
On Tue, Apr 12, 2005 at 01:30:08AM +0900, GOTO Masanori wrote:
OK, I put the patch. Currently I found the problem about schedutils.
Once schedutils `taskset' command uses new sched_getaffinity and
sched_setaffinity interface (which has GLIBC_2.3.4), schedutils has to
depend on glibc = 2.3.2.ds1-21.
I'm currently searching how to set Depends: libc6 (= 2.3.2.ds1-21) or
libc6.1 (= 2.3.2.ds1-21) [ia64, alpha] for schedutils.
BTW, if we change the library exported symbol version, GLIBC_2.3.4, we
should always bump up our shlibs from 2.3.2.ds1-4 to 2.3.2.ds1-21.
However, such change affects almost all binaries. Is this acceptable?
IMHO, changing shlibs affects a lot of packages, so I would like to
take the workaround fix - schedutils and fakeroot just have special
Depends: = 2.3.2.ds1-21, because I guess sched_{get,set}affinity is
not used widely.
I think that we should just be bumping the shlibdeps; the release team
has already agreed that we need a glibc update for sarge.
In any case, the best way to do what you want in schedutils mightb be:
Depends: ${shlib:Depends}
Conflicts: libc6 (= 2.3.2.ds1-21), libc6.1 (= 2.3.2.ds1-21)
I think that'll work... but make sure apt can cope.
Apt generally doesn't cope so well with = conflicts, as they tend to force
the removal of one of the packages on upgrade. Since libc6 isn't going to
get removed, apt generally resolves this as refusing to install or upgrade
the package that has this conflicts until libc is firs upgraded.
Given that other packages may in the future begin to depend on this
interface, I think this should really just be done as a shlibdeps bump.
Cheers,
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
Bug#297769: patch
At Thu, 24 Mar 2005 14:19:06 -0800, Steve Langasek wrote: On Thu, Mar 24, 2005 at 04:44:10PM +0100, Bastian Blank wrote: The attached patch updates sched_[gs]etaffinity to the new interface from glibc 2.3.4. I have difficulties with this patch. This patch adds new interface glibc 2.3.4 versioning symbol - it should not be in glibc 2.3.2 or 2.3.3. Investigation in the lintian lab on gluck.d.o shows that there are at least two packages, valgrind and schedutils, which would need to be updated to use the new API once this change is uploaded. Unfortunately, the data in that lintian lab is 9 months out-of-date, so a more thorough check is needed before this change can be allowed into sarge. I fear to change this interface until sarge release because there might be another packages that uses sched_setaffinity. I tender not to include the patch. I would like to call your opinion about Bastian's patch. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297769: patch
On Fri, 08 Apr 2005 15:32:29 +0900, GOTO Masanori [EMAIL PROTECTED]
said:
GOTO I fear to change this interface until sarge release because there
GOTO might be another packages that uses sched_setaffinity.
Well, yes, schedutils probably would need updating. I don't know of
anything else, though. We only care about the Debian packages for
sarge, I assume, right? If so, couldn't someone do a trivial find
across all sources for sched_{s,g}et_affinity? I'd be happy to
volunteer to fix all the packages that are affected (I'm not too
worried, the number will be very small, I'm sure of that).
GOTO I tender not to include the patch. I would like to call your opinion
GOTO about Bastian's patch.
That would really be unfortunate because it will mean that Debian is
incompatible with all other modern distributions. It's very likely
that it will cause a lot more grief down the road because new software
will break. For example, recent LMbench3 releases started to use
sched_setaffinity() and of course they use the correct (new)
interface...
--david
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297769: patch
On Fri, Apr 08, 2005 at 03:32:29PM +0900, GOTO Masanori wrote: At Thu, 24 Mar 2005 14:19:06 -0800, Steve Langasek wrote: On Thu, Mar 24, 2005 at 04:44:10PM +0100, Bastian Blank wrote: The attached patch updates sched_[gs]etaffinity to the new interface from glibc 2.3.4. I have difficulties with this patch. This patch adds new interface glibc 2.3.4 versioning symbol - it should not be in glibc 2.3.2 or 2.3.3. Investigation in the lintian lab on gluck.d.o shows that there are at least two packages, valgrind and schedutils, which would need to be updated to use the new API once this change is uploaded. Unfortunately, the data in that lintian lab is 9 months out-of-date, so a more thorough check is needed before this change can be allowed into sarge. I fear to change this interface until sarge release because there might be another packages that uses sched_setaffinity. I've confirmed that the lintian lab was up-to-date, in spite of some confusion about the timestamps on the directories. This means valgrind and schedutils are the only packages in Debian using this function currently, which means it's possible to update all of them at once. I tender not to include the patch. I would like to call your opinion about Bastian's patch. Well, there have been persuasive arguments why this patch is a good idea to include; persuasive enough that I left the bug at an RC severity. So my opinion is that it ought to be included... -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Bug#297769: patch
At Fri, 8 Apr 2005 00:11:07 -0700, Steve Langasek wrote: Investigation in the lintian lab on gluck.d.o shows that there are at least two packages, valgrind and schedutils, which would need to be updated to use the new API once this change is uploaded. Unfortunately, the data in that lintian lab is 9 months out-of-date, so a more thorough check is needed before this change can be allowed into sarge. I fear to change this interface until sarge release because there might be another packages that uses sched_setaffinity. I've confirmed that the lintian lab was up-to-date, in spite of some confusion about the timestamps on the directories. This means valgrind and schedutils are the only packages in Debian using this function currently, which means it's possible to update all of them at once. Thanks for your checking - lintian lab is very nice feature for us. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297769: patch
At Thu, 7 Apr 2005 23:46:51 -0700,
David Mosberger wrote:
GOTO I fear to change this interface until sarge release because there
GOTO might be another packages that uses sched_setaffinity.
Well, yes, schedutils probably would need updating. I don't know of
anything else, though. We only care about the Debian packages for
sarge, I assume, right? If so, couldn't someone do a trivial find
across all sources for sched_{s,g}et_affinity? I'd be happy to
volunteer to fix all the packages that are affected (I'm not too
worried, the number will be very small, I'm sure of that).
Yes, fixing this issue is not difficult.
The problem I concerned is the symbol GLIBC_PRIVATE is defined as
GLIBC_2.3.4, not the current symbol GLIBC_2.3.3. I'm not certain this
change does not cause any problems.
GOTO I tender not to include the patch. I would like to call your opinion
GOTO about Bastian's patch.
That would really be unfortunate because it will mean that Debian is
incompatible with all other modern distributions. It's very likely
that it will cause a lot more grief down the road because new software
will break. For example, recent LMbench3 releases started to use
sched_setaffinity() and of course they use the correct (new)
interface...
Indeed, but I would like to clear about the change of GLIBC_PRIVATE...
Regards,
-- gotom
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297769: patch
On Fri, Apr 08, 2005 at 10:04:17PM +0900, GOTO Masanori wrote: The problem I concerned is the symbol GLIBC_PRIVATE is defined as GLIBC_2.3.4, not the current symbol GLIBC_2.3.3. I'm not certain this change does not cause any problems. It is a chain of version definitions. But binaries only save the actual value of the version and don't depend on the chain, otherwise it won't be ever able to add version in the middle or drop versions. Also GLIBC_PRIVATE is only used by glibc itself, so the only source of problems may the different glibc packages. But I currently see nothing which may really cause problems here as ld.so is not effected. (See this as a small part of the upgrade to 2.3.4, with the exception that you don't break the compatiblity between ld.so and libc.so.6.) Bastian -- You! What PLANET is this! -- McCoy, The City on the Edge of Forever, stardate 3134.0 signature.asc Description: Digital signature
Bug#297769: patch
On Fri, Apr 08, 2005 at 10:04:17PM +0900, GOTO Masanori wrote:
At Thu, 7 Apr 2005 23:46:51 -0700,
David Mosberger wrote:
GOTO I fear to change this interface until sarge release because there
GOTO might be another packages that uses sched_setaffinity.
Well, yes, schedutils probably would need updating. I don't know of
anything else, though. We only care about the Debian packages for
sarge, I assume, right? If so, couldn't someone do a trivial find
across all sources for sched_{s,g}et_affinity? I'd be happy to
volunteer to fix all the packages that are affected (I'm not too
worried, the number will be very small, I'm sure of that).
Yes, fixing this issue is not difficult.
The problem I concerned is the symbol GLIBC_PRIVATE is defined as
GLIBC_2.3.4, not the current symbol GLIBC_2.3.3. I'm not certain this
change does not cause any problems.
It does not; Bastian's patch looks fine to me. I do this for glibc
backports on a regular basis.
The only thing that might be affected would be GLIBC_PRIVATE, and
nothing needs to be compatible with GLIBC_PRIVATE outside the glibc
packages. I don't think it will actually affect GLIBC_PRIVATE, either,
but I'd have to play around with it to make sure.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297769: patch
At Fri, 8 Apr 2005 15:31:56 +0200, Bastian Blank wrote: Also GLIBC_PRIVATE is only used by glibc itself, so the only source of problems may the different glibc packages. But I currently see nothing which may really cause problems here as ld.so is not effected. (See this as a small part of the upgrade to 2.3.4, with the exception that you don't break the compatiblity between ld.so and libc.so.6.) Yes, exactly, thinking about upgrade to 2.3.4, it should not make a problem. I'm rathar a bit nervous of supporting this special situation (ex: distro compatibility and so on) because -21 should be the last call for sarge stuff... Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297769: patch
On Sat, Apr 09, 2005 at 12:46:24AM +0900, GOTO Masanori wrote: At Fri, 8 Apr 2005 15:31:56 +0200, Bastian Blank wrote: Also GLIBC_PRIVATE is only used by glibc itself, so the only source of problems may the different glibc packages. But I currently see nothing which may really cause problems here as ld.so is not effected. (See this as a small part of the upgrade to 2.3.4, with the exception that you don't break the compatiblity between ld.so and libc.so.6.) Yes, exactly, thinking about upgrade to 2.3.4, it should not make a problem. I'm rathar a bit nervous of supporting this special situation (ex: distro compatibility and so on) because -21 should be the last call for sarge stuff... Could you explain what it is you're worried about? We absolutely ought to have this patch... -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297769: patch
tags 297769 patch
thanks
The attached patch updates sched_[gs]etaffinity to the new interface
from glibc 2.3.4.
Bastian
--
Phasers locked on target, Captain.
diff -ruN glibc-2.3.2.ds1/debian/changelog glibc-2.3.2.ds1.new/debian/changelog
--- glibc-2.3.2.ds1/debian/changelog2005-03-24 15:16:44.422281391 +
+++ glibc-2.3.2.ds1.new/debian/changelog2005-03-24 12:15:00.113925584
+
@@ -1,3 +1,11 @@
+glibc (2.3.2.ds1-20.1) unstable; urgency=low
+
+ * Bastian Blank [EMAIL PROTECTED]
+
+- Update sched_[gs]etaffinity to new interface. (closes: #297769)
+
+ -- Bastian Blank [EMAIL PROTECTED] Thu, 24 Mar 2005 12:14:44 +
+
glibc (2.3.2.ds1-20) unstable; urgency=high
* GOTO Masanori [EMAIL PROTECTED]
diff -ruN glibc-2.3.2.ds1/debian/patches/00list
glibc-2.3.2.ds1.new/debian/patches/00list
--- glibc-2.3.2.ds1/debian/patches/00list 2005-03-24 15:16:43.559278442
+
+++ glibc-2.3.2.ds1.new/debian/patches/00list 2005-03-24 13:55:17.071976008
+
@@ -116,3 +116,5 @@
s390-pthread-fpic
nptl-pthread-c++
hppa-drop-utimes
+libversion
+sched-update
diff -ruN glibc-2.3.2.ds1/debian/patches/libversion.dpatch
glibc-2.3.2.ds1.new/debian/patches/libversion.dpatch
--- glibc-2.3.2.ds1/debian/patches/libversion.dpatch1970-01-01
00:00:00.0 +
+++ glibc-2.3.2.ds1.new/debian/patches/libversion.dpatch2005-03-24
13:54:58.736966104 +
@@ -0,0 +1,32 @@
+#! /bin/sh -e
+
+# All lines beginning with `# DP:' are a description of the patch.
+# DP: Description: Update library versions
+# DP: Patch author: Bastian Blank [EMAIL PROTECTED]
+# DP: Date: 2005-03-24
+
+PATCHLEVEL=0
+
+if [ $# -ne 2 ]; then
+echo 2 `basename $0`: script expects -patch|-unpatch as argument
+exit 1
+fi
+case $1 in
+-patch) patch -d $2 -f --no-backup-if-mismatch -p$PATCHLEVEL $0;;
+-unpatch) patch -d $2 -f --no-backup-if-mismatch -R -p$PATCHLEVEL $0;;
+*)
+ echo 2 `basename $0`: script expects -patch|-unpatch as argument
+ exit 1
+esac
+exit 0
+
+--- Versions.def 2005-03-24 12:47:59.279008144 +
Versions.def 2005-03-24 13:53:32.651007992 +
+@@ -19,6 +19,7 @@
+ GLIBC_2.3.1
+ GLIBC_2.3.2
+ GLIBC_2.3.3
++ GLIBC_2.3.4
+ %ifdef USE_IN_LIBIO
+ HURD_CTHREADS_0.3
+ %endif
diff -ruN glibc-2.3.2.ds1/debian/patches/sched-update.dpatch
glibc-2.3.2.ds1.new/debian/patches/sched-update.dpatch
--- glibc-2.3.2.ds1/debian/patches/sched-update.dpatch 1970-01-01
00:00:00.0 +
+++ glibc-2.3.2.ds1.new/debian/patches/sched-update.dpatch 2005-03-24
14:27:00.818943936 +
@@ -0,0 +1,224 @@
+#! /bin/sh -e
+
+# All lines beginning with `# DP:' are a description of the patch.
+# DP: Description: Update sched_[gs]et_affinity to new interface
+# DP: Related bugs: 297769
+# DP: Patch author: Bastian Blank [EMAIL PROTECTED]
+# DP: Upstream status: Released
+# DP: Date: 2005-03-24
+
+PATCHLEVEL=0
+
+if [ $# -ne 2 ]; then
+echo 2 `basename $0`: script expects -patch|-unpatch as argument
+exit 1
+fi
+case $1 in
+-patch) patch -d $2 -f --no-backup-if-mismatch -p$PATCHLEVEL $0;;
+-unpatch) patch -d $2 -f --no-backup-if-mismatch -R -p$PATCHLEVEL $0;;
+*)
+ echo 2 `basename $0`: script expects -patch|-unpatch as argument
+ exit 1
+esac
+exit 0
+
+--- posix/sched.h 2005-03-24 12:08:26.376014592 +
posix/sched.h 2005-03-24 12:04:15.878891472 +
+@@ -73,11 +73,12 @@
+
+
+ /* Set the CPU affinity for a task */
+-extern int sched_setaffinity (__pid_t __pid, __const cpu_set_t *__mask)
+- __THROW;
++extern int sched_setaffinity (__pid_t __pid, size_t __cpusetsize,
++__const cpu_set_t *__cpuset) __THROW;
+
+ /* Get the CPU affinity for a task */
+-extern int sched_getaffinity (__pid_t __pid, cpu_set_t *__mask) __THROW;
++extern int sched_getaffinity (__pid_t __pid, size_t __cpusetsize,
++cpu_set_t *__cpuset) __THROW;
+ #endif
+
+ __END_DECLS
+--- sysdeps/generic/sched_getaffinity.c2005-03-24 12:08:26.502995288
+
sysdeps/generic/sched_getaffinity.c2005-03-24 12:00:21.055915184
+
+@@ -1,4 +1,4 @@
+-/* Copyright (C) 2002, 2003 Free Software Foundation, Inc.
++/* Copyright (C) 2002, 2003, 2004 Free Software Foundation, Inc.
+This file is part of the GNU C Library.
+
+The GNU C Library is free software; you can redistribute it and/or
+@@ -23,8 +23,9 @@
+
+ /* Retrieve the CPU affinity mask for a particular process. */
+ int
+-sched_getaffinity (pid, cpuset)
++sched_getaffinity (pid, cpusetsize, cpuset)
+ pid_t pid;
++ size_t cpusetsize;
+ cpu_set_t *cpuset;
+ {
+ __set_errno (ENOSYS);
+--- sysdeps/generic/sched_setaffinity.c2005-03-24 12:08:26.503995136
+
sysdeps/generic/sched_setaffinity.c2005-03-24 12:00:23.306972184
+
+@@ -1,4 +1,4 @@
+-/* Copyright (C) 2002, 2003 Free Software Foundation, Inc.
++/* Copyright (C) 2002, 2003, 2004 Free Software
Bug#297769: patch
On Thu, Mar 24, 2005 at 04:44:10PM +0100, Bastian Blank wrote: The attached patch updates sched_[gs]etaffinity to the new interface from glibc 2.3.4. Investigation in the lintian lab on gluck.d.o shows that there are at least two packages, valgrind and schedutils, which would need to be updated to use the new API once this change is uploaded. Unfortunately, the data in that lintian lab is 9 months out-of-date, so a more thorough check is needed before this change can be allowed into sarge. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
