[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7v7is4nt47.fsf@assigned-by-dhcp.cox.net>
Date: Sun, 22 Apr 2007 11:47:52 -0700
From: Junio C Hamano <junkio@....net>
To: Linus Torvalds <torvalds@...ux-foundation.org>
cc: "Randal L. Schwartz" <merlyn@...nehenge.com>,
Nicolas Pitre <nico@....org>
Subject: Re: [ANNOUNCE] GIT 1.5.1.2
Linus Torvalds <torvalds@...ux-foundation.org> writes:
> On Sat, 21 Apr 2007, Junio C Hamano wrote:
>>
>> The latest maintenance release GIT 1.5.1.2 is available at the
>> usual places:
>
> Well, by "available" you probably mean "not available", because it doesn't
> actually work.
>
> I get EPERM on pack-e00affefe0f779d0f9b0507aef25a1733f4a9117.idx/pack,
> because they are
>
> -r-------- 1 junio junio 1120880
> -r-------- 1 junio junio 15709370
>
> respectively.
> ...
> Oops.
Ok, to clarify the situation.
* This breakage does not make v1.5.1.2 is a dud release, as what
caused this is not contained in it.
* A topic to update git-pack-objects has been cooking in 'next'
and it graduated to 'master' last night after v1.5.1.2 was
cut from 'maint'. This series had a bug that left permission
bits as set by mkstemp(); newer glibc leaves it as 0600.
* I almost always run 'master' on kernel.org; I ran "git-repack
-a -d" there using 'master' that contained the breakage.
* git-repack lets git-pack-objects to create pack/idx, and then
drops the write permission bits from them. That is how they
got 0400.
* I've fixed the pack/idx 0444 manually at kernel.org; the
repository has already mirrored out to git.kernel.org, so
people should be able to fetch from there now. alt-git.git
at repo.or.cz should be usable as well, although I suspect
the site did not even have this issue.
* I sent a quickfix as a workaround. Because we rely on
git-repack to drop write permissions anyway, and some tests
to plumbing expects the resulting files to be writable by the
owner, tweaking 0444 in the quickfix to 0644 would be a good
workaround to fix the problem -and- pass all the test.
So I'll push out a 0644 quickfix on 'master' shortly.
However.
* To reiterate, people planning to update to v1.5.1.2 should
not be alarmed with this gotcha. That comes from the
maintenance branch and is not affected by this breakage.
* Letting mkstemp() to create the file and then forcing 0644 is
not strictly correct, as it makes the files created by people
with 007 umask readable to the general public. The code
before mkstemp() conversion was aware of this issue and used
open(..., 0666) to let the user's umask applied, I think.
So while the quickfix is an improvement, it not a real fix X-<.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists