|
Message-ID: <53CDA60C.6000701@barfooze.de> 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.