[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Exporting libc patches
From: |
Ludovic Courtès |
Subject: |
Re: Exporting libc patches |
Date: |
Mon, 06 Jun 2011 14:39:39 +0200 |
User-agent: |
Gnus/5.110017 (No Gnus v0.17) Emacs/24.0.50 (gnu/linux) |
Hi!
(I hear there’s a deadline approaching, so trying to see how I could do
something useful. ;-))
ludo@gnu.org (Ludovic Courtès) skribas:
> I’m looking at how to export patches from the
> ‘tschwinge/Roger_Whittaker’ branch to continuously test on Hydra whether
> they still apply to upstream glibc.
I eventually gave up on TopGit and went with:
git diff ea42a20caed5b343ff20a0d4622ae6c17b77161b > 00-glibc-hurd.patch
(The hash identifies the ‘baseline’ HEAD at the time...)
So now <http://hydra.nixos.org/job/gnu/glibc-hurd/hurd_patches> gives a
big glibc patch, which <http://hydra.nixos.org/job/gnu/glibc-hurd/tarball>
attempts to apply against glibc HEAD.
However, the patch currently fails to apply (see
<http://hydra.nixos.org/build/1108874>):
--8<---------------cut here---------------start------------->8---
applying patch
`/nix/store/6g995xp1w55k286xfv2qjanjslv41bq3-glibc-hurd-patches/00-glibc-hurd.patch'...
patching file .topdeps
patching file .topmsg
patching file bits/libc-lock.h
patching file bits/sched.h
Hunk #1 succeeded at 141 with fuzz 2 (offset 72 lines).
[...]
patching file include/unistd.h
Hunk #1 FAILED at 79.
1 out of 1 hunk FAILED -- saving rejects to file include/unistd.h.rej
--8<---------------cut here---------------end--------------->8---
‘unistd.h.rej’ looks like this (from
<http://hydra.nixos.org/build/1108874/download/1/glibc-tarball-0pref16846a5f279b4eb5f80821e8d27ffa73b1a1f7d/nix-build-7jfdkii209law05vv7w8452l9h3kpqkz-glibc-tarball-0pref16846a5f279b4eb5f80821e8d27ffa73b1a1f7d.drv-0/git-export/include/unistd.h.rej>):
--- include/unistd.h
+++ include/unistd.h
@@ -79,6 +79,8 @@
extern int __dup (int __fd);
extern int __dup2 (int __fd, int __fd2);
libc_hidden_proto (__dup2)
+extern int __dup3 (int __fd, int __fd2, int __flags);
+libc_hidden_proto (__dup3)
extern int __execve (__const char *__path, char *__const __argv[],
char *__const __envp[]);
extern long int __pathconf (__const char *__path, int __name);
Ideas?
Alternatively, should I rather use the Debian glibc repo as the patch
source?
Thanks,
Ludo’.
- Re: Exporting libc patches,
Ludovic Courtès <=