#1916 chmod in $CVSROOT/gdb/*
Closed: Fixed None Opened 9 years ago by jkratoch.

= phenomenon =
{{{
cd rpms/gdb/F-12
F="gdb-6.8-bz457187-largefile-test.patch gdb-ppc-hw-watchpoint-twice.patch"
rm $F; cvs update $F; ls -l $F
-rwxr-xr-x 1 jkratoch jkratoch 4502 2010-01-08 00:33 gdb-6.8-bz457187-largefile-test.patch
-rwxr-xr-x 1 jkratoch jkratoch 644 2010-01-08 00:33 gdb-ppc-hw-watchpoint-twice.patch

}}}
The +x execute permission is incorrect there.

= background analysis =
According to my knowledge I cannot change the {{{x}}} permission after the {{{,v}}} file has been created in the repository

= implementation recommendation =
{{{
cd rpms/gdb
chmod -x /.patch,v
}}}


Is the +x causing some real problem?
If so I can fix it, but not sure what issue it could cause...

No real functionality problem.

But I imported the Fedora package to Red Hat PkgWrangler and it complains on these permissions. Expecting Fedora also may get some such tool.

It is just more correct to have *.patch files without "x".

well, I can fix the files on the cvs server, but I have never heard of PkgWrangler.
Does it say why it doesn't like those permissions?

Possible issues here:
- If lots of packagers start using this how are we going to scale the process of fixing potentially lots of files?
- We are migrating to git soon anyhow, does PkgWrangler handle git? Does it have the same complaint there? Do we need to do something else when we import to git?

Replying to [comment:3 kevin]:

well, I can fix the files on the cvs server, but I have never heard of PkgWrangler.

It's an internal RH tool used for tracking package information.

Does it say why it doesn't like those permissions?

I suppose because they're pointless for patch files.

Possible issues here:
- If lots of packagers start using this how are we going to scale the process of fixing potentially lots of files?
{{{
find /cvs/pkgs -name *.patch,v -perm +x -exec chmod 644 {} \
}}}

Or something similar, that line isn't tested.

  • We are migrating to git soon anyhow, does PkgWrangler handle git? Does it have the same complaint there? Do we need to do something else when we import to git?

I think it's just complaining about the patches being 0755 in the generated source rpm.

Oh, I guess I don't have access to fix this on the cvs box. ;(

We could do a script to -x all the patch files, but how often do we run this?
Would be a bit on the I/O heavy side of things.

Perhaps fixing them before importing to git and see if we can make it so they automagically get -x when added to git would be the way to go?

To bring this issue back to the Fedora world, I was giving Jan hard time for this on his Merge Review https://bugzilla.redhat.com/show_bug.cgi?id=225783 :)

Closing, we've moved to git, where this should now be self-service.

Login to comment on this ticket.

Metadata