On 10/31/2011 4:19 AM, Erwin Waterlander wrote:
> On 10/28/2011 11:47 AM, Keith Marshall wrote:
>> One further quibble, (also minor): there should be an<affiliate ... />
>> declaration , e.g.:
>> <package name="mingw32-libunistring" alias="libunistring">
>> +<affiliate group="MinGW Contributed Libraries" />
>> <description lang="en" title="libunistring: ...
> I added the proposed affiliate declaration to the xml file.
I uploaded the packages to frs, using 'MinGW/Contributed/libunistring'.
I also uploaded the manifest, with the affiliate group above, to the
I did **not** do the following:
1) $whatever is required, in mingw-dist, to cause
mingw32-libunistring.xml.lzma to be "included" in mingw-get's working
set -- mainly because I wasn't sure what was required, when the .xml
file is not maintained in mingw-dist itself.
2) Move MinGW/PDCurses/ to MinGW/Contributed/PDCurses -- because (a) I'm
not sure if sftp allows to "move" directories. It provides a 'rename'
command, and I tried:
rename PDCurses Contributed/PDCurses
but that failed, because either (a) rename doesn't allow that operation,
or (b) I didn't have appropriate permissions. [*] If it is a limitation
of the rename command, then the alternative (which avoids downloading
and re-uploading everything) is to recreate the directory structure in
the new location, then to use sftp's 'ln' command to create hardlinks to
all the files, and finally to remove the "old" files. Of course, I'd
test one file first (with d/l'ed backup) just to make sure sftp ln does
what I think, before deleting ALL the files from the old location...
3) Remove mingw32/mingw32-pdcurses.xml from mingw-dist, and $whatever is
required to make mingw-get still USE the sf.net-based
mingw32-pdcurses.xml.lzma, while allowing mingw-dist's build procedure
to "skip" trying to build the file (maybe nothing?).
[*] Pet peeve: please, when you upload to sf.net, or create new
directories, make sure the chmod all dirs as 775, and all files as 664.
Erwin "owns" the PDCurses directory (rwxr-xr-x), so I couldn't move it.
There are quite a few other dirs and files without group write
permission. If you have access to frs, please log on and fix the files
that you can.
Earnie: is there any way to make sure the default "remote umask" on frs
is 002, not 022? Or is there a way to make that "sticky" -- at least
under the MinGW/, MSYS/, and Automated MinGW Installer/ directories?
Alternatively, can we manipulate the frs from an ssh session -- and if
so, who has the requisite administrative karma to turn
on existing files which are owned by another project member?