[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 22 Jul 2014 01:45:16 +0200
From: John Spencer <maillist-musl@...fooze.de>
To: glommer@...udius-systems.com
CC: musl@...ts.openwall.com
Subject: Re: [PATCH] implement glibc's glob_pattern_p
Rich Felker wrote:
> On Mon, Jul 21, 2014 at 02:29:59PM +0400, Glauber Costa wrote:
>>> they seem to have copied a lot of code from musl, but
>>> never said a word about it here.. would be nice to know
>>> where they are going with it.. or why they decided to
>>> use musl in the first place
>>>
>> I am sorry about that! The decision to use musl was a very early
i was not delighted when i saw some of the musl code turned into C++ in
the osv repo...
>
> No need to be sorry. I think nsz just wanted to alert you that there
> might be serious bugs that should be fixed if you're going to continue
> to use a fork. The WHATSNEW file does a pretty good job of summarizing
> important fixes in each release and could be used to find patches to
> backport.
my idea to keep a fork in tune using a semi-automated approach:
- use a comment line like // SOURCE: $MUSL/src/unistd/getpid.c in every
file in libc/ that's copied from musl
- use a shell script that updates a musl clone and then iterates over
the files in osv/libc, and for each file that contains SOURCE tag do
"git log -p $MUSL/$SOURCE" to see an overview of all commits and changes
to that file.
you could even add the commit id from which the source was imported as
another comment to restrict the set of changes that's shown to only the
relevant ones. after backporting changes, you could manually raise the
commit id to the one of the corresponding musl commit.
if done like regularly, like once a month, you could probably get away
with very little work to get all the relevant changes backported.
--JS
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
