mingw-msys Mailing List for MinGW - Minimalist GNU for Windows

On 19/03/2011 12:31 PM, Charles Wilson wrote:
> On 3/19/2011 9:19 AM, Chris Sutcliffe wrote:
> Anyway, did you run the vim testsuite?
>> That I didn't do.  I'm updating my build script to run it now and will
>> include it in the next release.
> It's a bit tiresome.  And IIRC you have to attend it, there are some
> points that it needs user input I think, at least on msys.

I've run it now and only test49 fails, which is expected and can be 
corrected as per the instructions in the test itself.

>> Thank you for taking the time to review the package.
> It's a lot easier than rebuilding it myself, so thank YOU.  I'll take a
> look at your -2 release in a day or so.

I've released 7.3-2 now, so please let me know what you think.

Cheers!

Chris

On 3/19/2011 9:43 AM, Keith Marshall wrote:
> On 19/03/11 05:49, Charles Wilson wrote:
>> Ah...which is yet another reason why you couldn't automate this *inside
>> an msys shell*.  We don't provide mercurial.
> 
> However, the stock Win32 build from mercurial's own web site runs just
> fine, as a native Win32 application run from an MSYS shell.  If it
> weren't for a pathological reluctance to adopt tools we haven't built
> for ourselves, I myself would choose mercurial over git every time.

Well, there's a difference between the current case, where somebody who
wants to update msys-vim to a version newer than that bundled inside
Chris's -src tarball would need to have mercurial to do so, and

Anybody who wants to develop/modify the software we maintain (mingw-get,
MSYS itself, etc) would need mercurial/git/etc.

In the former case, I don't see much problem "requiring" a tool we don't
provide.  In the latter case...I find that more problematic, especially
if the tool in question requires Visual anything, to be compiled on win32.

--
Chuck

On 3/19/2011 9:19 AM, Chris Sutcliffe wrote:
> I've repackaged vim 7.3 and included a build script and an MSYS specific 
> README (based on your RELEASE_NOTES).  I've even remembered to add the 
> '.exe' extension to the hardlinked files.  ;)

Thanks -- I really did not mean to imply you must, or even should, take
the time to do this right now, for 7.3.  But I'm glad you did.

>> Ah...which is yet another reason why you couldn't automate this *inside
>> an msys shell*.  We don't provide mercurial.
> 
> Exactly, the README provides details on how to pull vim source using 
> Mercurial.

OK.  I'm not concerned about our "pathological reluctance" regarding
external tools in this case, because anyone who wants to rebuild 7.3-N
will already HAVE the source tarball, and won't need mercurial.

And, of course, the evil RHEL bundled patch issue doesn't apply when the
DCVS repository is exposed to the world.

>> Well, that's why it is a suggestion, not a command. (I'll point out
>> again that w32api and mingwrt are "special"... and gdb.  Dang, gdb.
> 
> I've seen the light and added an automated build script (it made my life 
> easier ;) ).

Ack.

>> Well, if EVER there was an msys package that could use some
>> documentation on how to get the darned thing built and working on msys,
>> it's gdb...
> 
> Indeed, the next time I package gdb I'll add an automated build script, 
> including make, since they both are finicky to build.

Talk about understatements...<g>

>> Also, oould you speak more to the "vim-7.3 builds out of the box on
>> msys" thing?  We don't typically send MSYS patches upstream; we
>> typically #define __CYGWIN__ and adapt as necessary.
> 
> It's not needed, something Andy and I figured out when porting mintty.  
> This was run from an 'msysdvlpr' shell:
> 
> Chris@Chris-PC ~
> $ gcc -dM -E - < /dev/null | grep CYGWIN
> #define __CYGWIN__ 1
> #define __CYGWIN32__ 1

Oh yeah, right.  Duh.  I was the one who asked Cesar to make that happen.

>> 	$ objdump -p vim.exe | grep fchdir
>> 	<nothing>
>>
>> Hmm.  Maybe not.
> 
> I saw that you had specifics around fchdir in your patch set, but as 
> you've also noticed, I assume vim's configure must now either not use 
> fchdir or check to see if it's broken and work around it.

Looks that way.

>> Anyway, did you run the vim testsuite?
> 
> That I didn't do.  I'm updating my build script to run it now and will 
> include it in the next release.

It's a bit tiresome.  And IIRC you have to attend it, there are some
points that it needs user input I think, at least on msys.

> I'm going to upload a '-2' release with these changes, as my Grandfather 
> used to say, "if a job's worth doing, it's worth doing right". :)

<g>

> Thank you for taking the time to review the package.

It's a lot easier than rebuilding it myself, so thank YOU.  I'll take a
look at your -2 release in a day or so.

--
Chuck

On 19/03/11 05:49, Charles Wilson wrote:
>> Actually I didn't work that hard at all, I simply pulled that latest
>> source from Mercurial, so no manual patching was required.
> 
> Ah...which is yet another reason why you couldn't automate this *inside
> an msys shell*.  We don't provide mercurial.

However, the stock Win32 build from mercurial's own web site runs just
fine, as a native Win32 application run from an MSYS shell.  If it
weren't for a pathological reluctance to adopt tools we haven't built
for ourselves, I myself would choose mercurial over git every time.

-- 
Regards,
Keith.

On 19/03/2011 1:49 AM, Charles Wilson wrote:
> On 3/18/2011 5:51 PM, Chris Sutcliffe wrote:
>> On 18/03/2011 5:23 PM, Charles Wilson wrote:
>>> In the FRS release area, there's no release notes.
>>> There's no [/usr]/share/doc/MSYS/vim-7.3-1-msys.RELEASE_NOTES.txt
>>> either, so that's probably why.
>> Fair enough, I'll capture my build instructions there.
> Yep...that makes it easier to keep notes like
>    + Remember to make sure the bin/* hardlinks to vim.exe
>      all have .exe extensions...
> :-)

I've repackaged vim 7.3 and included a build script and an MSYS specific 
README (based on your RELEASE_NOTES).  I've even remembered to add the 
'.exe' extension to the hardlinked files.  ;)

>>> Frankly, I'm surprised that you seem to have worked *harder* -- manually
>>> installing 37 different patches (1-100, +101..138) to generate the -src
>>> package, and apparently manually typing commands to create the various
>>> .tar.lzma's -- than simply re-using and editing the existing automated
>>> structure from vim-7.2-2-src's msys-build-vim script.
>> Actually I didn't work that hard at all, I simply pulled that latest
>> source from Mercurial, so no manual patching was required.
> Ah...which is yet another reason why you couldn't automate this *inside
> an msys shell*.  We don't provide mercurial.

Exactly, the README provides details on how to pull vim source using 
Mercurial.

>>> So...I suggest that for the next revision, whenever anybody feels like
>>> it or gets around to it, restore some of these items like release notes
>>> and automated build scripts.
>> I agree with the release notes, but I'm not sure about the automated
>> build scripts, since I have never supplied them before with any other
>> package I've provided (I seem to remember having this discussion before
>> but can't seem to find a reference to it).
> Well, that's why it is a suggestion, not a command. (I'll point out
> again that w32api and mingwrt are "special"... and gdb.  Dang, gdb.

I've seen the light and added an automated build script (it made my life 
easier ;) ).

> Well, if EVER there was an msys package that could use some
> documentation on how to get the darned thing built and working on msys,
> it's gdb...

Indeed, the next time I package gdb I'll add an automated build script, 
including make, since they both are finicky to build.

> Also, oould you speak more to the "vim-7.3 builds out of the box on
> msys" thing?  We don't typically send MSYS patches upstream; we
> typically #define __CYGWIN__ and adapt as necessary.

It's not needed, something Andy and I figured out when porting mintty.  
This was run from an 'msysdvlpr' shell:

Chris@Chris-PC ~
$ gcc -dM -E - < /dev/null | grep CYGWIN
#define __CYGWIN__ 1
#define __CYGWIN32__ 1

> (Oh, and vim-7.2 relies on a particular posix-conforming behavior of
> fchdir IF fchdir() exists.  MSYS has fchdir() but it is broken in a
> particular case, which vim doesn't like.  Hence, 7.2-2 does this:
>
>    ### avoid fchdir, force termcap
>    export ac_cv_func_fchdir=no
>    export vim_cv_terminfo=no
>
> prior to running configure. (Looks like the terminfo/termcap thing isn't
> necessary with 7.3, but I bet the other is...
>
> 	$ objdump -p vim.exe | grep fchdir
> 	<nothing>
>
> Hmm.  Maybe not.

I saw that you had specifics around fchdir in your patch set, but as 
you've also noticed, I assume vim's configure must now either not use 
fchdir or check to see if it's broken and work around it.

> Anyway, did you run the vim testsuite?

That I didn't do.  I'm updating my build script to run it now and will 
include it in the next release.

> I'm not saying you HAVE to do a build script, nor that if you do that it
> must look like the one from 7.2.  Or that you should bother right now,
> while trying to get 7.3 done.  (Maye for 7.4...)

I'm going to upload a '-2' release with these changes, as my Grandfather 
used to say, "if a job's worth doing, it's worth doing right". :)

Thank you for taking the time to review the package.

Chris

On 3/18/2011 5:51 PM, Chris Sutcliffe wrote:
> On 18/03/2011 5:23 PM, Charles Wilson wrote:
>> On 3/18/2011 4:29 PM, Chris Sutcliffe wrote:
>>> --with-features=huge
>> Doesn't this mean that msys-perl is now required? Or is that just if you
>> want to use the (pseudo)embedded perl functionality?
> 
> I don't believe so, :version reports '-perl':

Right; perl support requires to be explicitly enabled, even if +huge.

>> BTW, it's usually been the convention that msys packages are configured
>> with --prefix=/usr and not /, *EVEN THOUGH* /usr is identical to / given
>> the enforced MSYS mount structure.  I'm not sure it makes a difference
>> -- but it costs nothing so I'm not really sure why it should be changed.
> 
> I tried that at first, but the DESTDIR captures '/usr' in the tarball,
> so I dropped it to '/'.  I suppose I could filter out '/usr' when
> creating  the tarball.

Yep, that's the way we've been doing them:
  --prefix=/usr
  make install DESTDIR=/foo
  (cd /foo/usr && tar -cvf ...)

>> In the FRS release area, there's no release notes.
>> There's no [/usr]/share/doc/MSYS/vim-7.3-1-msys.RELEASE_NOTES.txt
>> either, so that's probably why.
> 
> Fair enough, I'll capture my build instructions there.

Yep...that makes it easier to keep notes like
  + Remember to make sure the bin/* hardlinks to vim.exe
    all have .exe extensions...
:-)

>> Frankly, I'm surprised that you seem to have worked *harder* -- manually
>> installing 37 different patches (1-100, +101..138) to generate the -src
>> package, and apparently manually typing commands to create the various
>> .tar.lzma's -- than simply re-using and editing the existing automated
>> structure from vim-7.2-2-src's msys-build-vim script.
> 
> Actually I didn't work that hard at all, I simply pulled that latest
> source from Mercurial, so no manual patching was required.

Ah...which is yet another reason why you couldn't automate this *inside
an msys shell*.  We don't provide mercurial.

>> So...I suggest that for the next revision, whenever anybody feels like
>> it or gets around to it, restore some of these items like release notes
>> and automated build scripts.
> 
> I agree with the release notes, but I'm not sure about the automated
> build scripts, since I have never supplied them before with any other
> package I've provided (I seem to remember having this discussion before
> but can't seem to find a reference to it).

Well, that's why it is a suggestion, not a command. (I'll point out
again that w32api and mingwrt are "special"... and gdb.  Dang, gdb.
Well, if EVER there was an msys package that could use some
documentation on how to get the darned thing built and working on msys,
it's gdb...


The main reason for *automation* -- as opposed to documentation -- is to
*specifically* allow other maintainers to come in and easily reproduce
your work, in the event of a security fix, bus+Linus event, etc.  And,
since documentation always gets out of date, automated build scripts
force an eat-your-own-dogfood mentality.

Without such a script (or, if an earlier script already exists but one
ignores it), then anyone attempting to rescue a floundering package
basically has to start from scratch -- and previous lessons learned get
forgotten. (Case in point: the .exe thing was a bug fix at some point,
and was captured in the build script as part of the msys_install() function:

  ...
  pushd ${instdir}${PREFIX}/bin 2>/dev/null
  for f in ex rview rvim view vimdiff
  do
    if [ -e $f ]
    then
      rm -f $f
    fi
    if [ -e $f.exe ]
    then
      rm -f $f.exe
    fi
    ln vim.exe $f.exe
  done
  popd 2>/dev/null
  ...

Also, oould you speak more to the "vim-7.3 builds out of the box on
msys" thing?  We don't typically send MSYS patches upstream; we
typically #define __CYGWIN__ and adapt as necessary.

We don't normally #define __CYGWIN32__ and your ./configure recipe
didn't mention CFLAGS settings.

While cygwin's gcc defines that old macro -- and lots of vim source is
(was?) conditionalized on the __CYGWIN32__ variant.  Hence the
	vim-7.2-2-msys.patch
So unless you added both -D__CYGWIN__ -D__CYGWIN32__ to CFLAGS, or
upstream (finally) switched to all __CYGWIN__ and no __CYGWIN32__ AND
you added -D__CYGWIN__, or upstream magically added also #if
defined(__MSYS__) conditionals...I'm concerned.  Unless something fancy
is happening behind the scenes, msys-vim won't be compiled with any of
the necessary *cygwin*izations.

(Oh, and vim-7.2 relies on a particular posix-conforming behavior of
fchdir IF fchdir() exists.  MSYS has fchdir() but it is broken in a
particular case, which vim doesn't like.  Hence, 7.2-2 does this:

  ### avoid fchdir, force termcap
  export ac_cv_func_fchdir=no
  export vim_cv_terminfo=no

prior to running configure. (Looks like the terminfo/termcap thing isn't
necessary with 7.3, but I bet the other is...

	$ objdump -p vim.exe | grep fchdir
	<nothing>

Hmm.  Maybe not.

Anyway, did you run the vim testsuite?

I'm not saying you HAVE to do a build script, nor that if you do that it
must look like the one from 7.2.  Or that you should bother right now,
while trying to get 7.3 done.  (Maye for 7.4...)

It's just...why not use the script?  It's already there and just needs
tweaking for 7.N+1 most likely...

My build scripts are structured like this, BTW:

#/bin/sh
... setup and var defs ...
... function definitions ...
# and nothing /actually happens/ until the very end,
# where the functions are invoked one after another:

msys_conf_prep
msys_conf
msys_build
msys_check
msys_install
msys_package

This makes for (relatively) easy step-wise operation, by commenting out
various lines at the end of the script.  That gets tricky vs.
msys_package().  I tend to do this:


# msys_conf_prep
# msys_conf
# msys_build
# msys_check
# msys_install
sleep 30
msys_package

And then, after invoking the script for my piecewise 'package' step, I
edit the script from another window -- while the original window is
stuck in the sleep 30 -- to un-comment-out the lines and remove the
sleep.  This way the package gets a do-it-all version of the build script.

/that's/ a bit clunky, but I didn't want to add an arg-parsing loop to
the build script. At least not until I go /all out/ and finish the
msysport project...

--
Chuck

On 18/03/2011 5:30 PM, Charles Wilson wrote:
> Which may be sooner rather than later. Chris, in order to work nicely
> with cmd.exe, the hardlinked (copies) of vim.exe should all have .exe
> endings...(vimtutor is a shell script, xxd.exe is a different prog)

Hrmm....  I suppose.  This is an 'msys' package, so I suppose it could 
be argued that it shouldn't be called directly from cmd.exe, but point made.

I'll address this and the other concerns you've raised in a new release 
later tonight.

Cheers!

Chris

On 18/03/2011 5:23 PM, Charles Wilson wrote:
> On 3/18/2011 4:29 PM, Chris Sutcliffe wrote:
>> --with-features=huge
> Doesn't this mean that msys-perl is now required? Or is that just if you
> want to use the (pseudo)embedded perl functionality?

I don't believe so, :version reports '-perl':

Huge version without GUI.  Features included (+) or not (-):
+arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset 
+cindent -clientserver -clipboard +cmdline_compl +cmdline_hist
+cmdline_info +comments +conceal +cryptv +cscope +cursorbind 
+cursorshape +dialog_con +diff +digraphs -dnd -ebcdic +emacs_tags
+eval +ex_extra +extra_search +farsi +file_in_path +find_in_path +float 
+folding -footer +fork() +gettext -hangul_input +iconv
+insert_expand +jumplist +keymap +langmap +libcall +linebreak 
+lispindent +listcmds +localmap -lua +menu +mksession +modify_fname
+mouse -mouseshape +mouse_dec -mouse_gpm -mouse_jsbterm +mouse_netterm 
-mouse_sysmouse +mouse_xterm +multi_byte +multi_lang
-mzscheme +netbeans_intg -osfiletype +path_extra -perl +persistent_undo 
+postscript +printer +profile -python -python3 +quickfix
+reltime +rightleft -ruby +scrollbind +signs +smartindent -sniff 
+startuptime +statusline -sun_workshop +syntax +tag_binary
+tag_old_static -tag_any_white -tcl -terminfo +termresponse +textobjects 
+title -toolbar +user_commands +vertsplit +virtualedit
+visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows 
+writebackup -X11 -xfontset -xim -xsmp -xterm_clipboard
-xterm_save

> BTW, it's usually been the convention that msys packages are configured
> with --prefix=/usr and not /, *EVEN THOUGH* /usr is identical to / given
> the enforced MSYS mount structure.  I'm not sure it makes a difference
> -- but it costs nothing so I'm not really sure why it should be changed.

I tried that at first, but the DESTDIR captures '/usr' in the tarball, 
so I dropped it to '/'.  I suppose I could filter out '/usr' when 
creating  the tarball.

> In the FRS release area, there's no release notes.
> There's no [/usr]/share/doc/MSYS/vim-7.3-1-msys.RELEASE_NOTES.txt
> either, so that's probably why.

Fair enough, I'll capture my build instructions there.

> Frankly, I'm surprised that you seem to have worked *harder* -- manually
> installing 37 different patches (1-100, +101..138) to generate the -src
> package, and apparently manually typing commands to create the various
> .tar.lzma's -- than simply re-using and editing the existing automated
> structure from vim-7.2-2-src's msys-build-vim script.

Actually I didn't work that hard at all, I simply pulled that latest 
source from Mercurial, so no manual patching was required.

> So...I suggest that for the next revision, whenever anybody feels like
> it or gets around to it, restore some of these items like release notes
> and automated build scripts.

I agree with the release notes, but I'm not sure about the automated 
build scripts, since I have never supplied them before with any other 
package I've provided (I seem to remember having this discussion before 
but can't seem to find a reference to it).

> One of these days I'll finish my "msysport" tool, a bastardization of
> cygwin's cygport.  simple gentoo ebuild-like scripts to create msys
> packages, mmmmm....

I look forward to having something like this.  ;)

Cheers!

Chris

On 3/18/2011 5:23 PM, Charles Wilson wrote:
> So...I suggest that for the next revision, whenever anybody feels like
> it or gets around to it, restore some of these items like release notes
> and automated build scripts.

Which may be sooner rather than later.  Chris, in order to work nicely
with cmd.exe, the hardlinked (copies) of vim.exe should all have .exe
endings...(vimtutor is a shell script, xxd.exe is a different prog)

msys-7.2-2
-rwxr-xr-x cwilson/admin 1399808 2010-04-26 22:04 bin/ex.exe
-rwxr-xr-x cwilson/admin 1399808 2010-04-26 22:04 bin/rview.exe
-rwxr-xr-x cwilson/admin 1399808 2010-04-26 22:04 bin/rvim.exe
-rwxr-xr-x cwilson/admin 1399808 2010-04-26 22:04 bin/view.exe
-rwxr-xr-x cwilson/admin 1399808 2010-04-26 22:04 bin/vim.exe
-rwxr-xr-x cwilson/admin 1399808 2010-04-26 22:04 bin/vimdiff.exe
-rwxr-xr-x cwilson/admin    2084 2010-04-26 22:04 bin/vimtutor
-rwxr-xr-x cwilson/admin   13824 2010-04-26 22:04 bin/xxd.exe

msys-7.3-1
-rwxr-xr-x Chris/admin 1542144 2011-03-18 13:31 bin/ex
-rwxr-xr-x Chris/admin 1542144 2011-03-18 13:31 bin/rview
-rwxr-xr-x Chris/admin 1542144 2011-03-18 13:31 bin/rvim
-rwxr-xr-x Chris/admin 1542144 2011-03-18 13:31 bin/view
-rwxr-xr-x Chris/admin 1542144 2011-03-18 13:31 bin/vim.exe
-rwxr-xr-x Chris/admin 1542144 2011-03-18 13:31 bin/vimdiff
-rwxr-xr-x Chris/admin    2084 2011-03-18 13:31 bin/vimtutor
-rwxr-xr-x Chris/admin   13824 2011-03-18 13:31 bin/xxd.exe


Short term fix: you could simply unpack -bin, rename the executables,
and re-upload the new -bin archive with the same name, version, and
release number, since few people will be affected if you do it soon.

--
Chuck

On 3/18/2011 4:29 PM, Chris Sutcliffe wrote:

> --with-features=huge

Doesn't this mean that msys-perl is now required? Or is that just if you
want to use the (pseudo)embedded perl functionality?

BTW, it's usually been the convention that msys packages are configured
with --prefix=/usr and not /, *EVEN THOUGH* /usr is identical to / given
the enforced MSYS mount structure.  I'm not sure it makes a difference
-- but it costs nothing so I'm not really sure why it should be changed.


FYI, I'm not entirely thrilled with the -src packaging. At least with
7.3 there is no more issue with combining upstream's separate "src" and
"rt" tarballs, as upstream now packages them together.

However, you've marked this as patchlevel 138, so I can only assume the
msys-src tarball has already had those patches applied.  Hmm...shades of
the ongoing RHEL 6.0 kernel sources controversy:
	http://lwn.net/Articles/431854/
	http://lwn.net/Articles/432012/

There's no build script (or even simply build instructions, other than
your mailing list post which given gmane and sourceforge's abysmal
search facilities, will effectively by lost in the ether within a month
or two).

In the FRS release area, there's no release notes.
There's no [/usr]/share/doc/MSYS/vim-7.3-1-msys.RELEASE_NOTES.txt
either, so that's probably why.

Frankly, I'm surprised that you seem to have worked *harder* -- manually
installing 37 different patches (1-100, +101..138) to generate the -src
package, and apparently manually typing commands to create the various
.tar.lzma's -- than simply re-using and editing the existing automated
structure from vim-7.2-2-src's msys-build-vim script.

But, you know what?

I didn't have to do it.

So...I suggest that for the next revision, whenever anybody feels like
it or gets around to it, restore some of these items like release notes
and automated build scripts.


One of these days I'll finish my "msysport" tool, a bastardization of
cygwin's cygport.  simple gentoo ebuild-like scripts to create msys
packages, mmmmm....

--
Chuck

I've packaged vim 7.3.138 as vim 7.3-1 for MSYS.  It's available via 
mingw-get:

mingw-get update
mingw-get install msys-vim

or if you already have it installed:

mingw-get update
mingw-get upgrade msys-vim

I configured vim with the following options:

./configure --prefix=/ \
--wit...@us... \
--datarootdir=/share \
--docdir=/share/doc/vim/7.3 \
--sbindir=/sbin \
--libexecdir=/sbin \
--sysconfdir=/etc \
--localstatedir=/var \
--disable-gui \
--with-tlib=termcap \
--with-features=huge

vim now builds out of the box for MSYS without any modification.

Please report any issues to this mailing list.

Thank you,

Chris

On 17 March 2011 14:16, Edward Diener wrote:
> How does one determine the PATH in MSYS for which executables are searched ?

  echo $PATH

-- 
Regards,
Keith.

How does one determine the PATH in MSYS for which executables are searched ?

On 16 March 2011 22:24, Page, Andy (UK) wrote:
> I have come to update MSYS and can nolonger find my way around the
> install process, ( alright i am dumb etc ...). I tried the automatic
> installer ( even though i did not want MINGW and wanted more than a
> the base MSYS system).

FTR, mingw-get itself does NOT insist that you install MinGW, (although
Chuck's mingw-get-inst may do).  If you follow the instructions on the
download site, to install just mingw-get, without using mingw-get-inst,
then you can 'mingw-get install msys-tiny' (or msys-base), and then
cherry pick any additional packages you require.  Hint:

  $ mingw-get list 2>/dev/null | awk '
      /^Package:/{print $3, $4 ";", $1, $2}
      /^Components*:/{print $0 "\n"}'

will display a list of package names, and associated component packages,
(after you've installed msys-base, or msys-tiny + msys-awk).

> however the installer did not work probably becuase i am using it from
> behind a firewall and would normally need to supply a http-proxy to
> other tools like wget.

Improving the handling of authenticating proxy issues is the next item
on my to-do list.  However, I will need assistance from the community,
since, although I too am behind an authenticating proxy server, the
authentication is handled automatically by the PDC, and the present
mingw-get implementation works perfectly for me, so I have no way to
test any changes I make wrt this task.

> So resorting to a manual install and totally daunted by the numbers of
> versions and, i.e. i would like msys1.0.16 with openssl which seems to
> only be made for msys1.0.13, other packages dont have any reliance of
> the msys release.

That's okay.  Where the package indicates an MSYS version, (as all MSYS
packages should; it's only mingw32 packages which don't), that is the
MINIMUM msys-1.0.dll release for which the package has been tested; I'm
not aware of any which won't work with a newer release of msys-1.0.dll.

> Can someone indicate a way forward for me please ??

- Use wget to download mingw-get-0.2-mingw32-alpha-2-bin.zip; unpack it
  in C:\MinGW, (or your preferred alternative, but please, no spaces in
  the path name).  Add C:\MinGW\bin (or equivalent) to PATH.

- Set up C:\MinGW\var\lib\mingw-get\data\profile.xml, as described on
  the download site, (or copy/rename defaults.xml).

- If your proxy blocks mingw-get from downloading, use wget to download
  (recursively) the entire *.xml.lzma content from the Catalogue folder
  on the download host; place them in C:\MinGW\var\lib\mingw-get\data
  and uncompress (unlzma) them.

- Run 'mingw-get install ...' for the packages you wish to install, with
  stderr redirected to a log file.  Note any URLs logged as failed to
  download; use wget or a browser to download them manually, and place
  them into C:\MinGW\var\cache\mingw-get\packages

- Run 'mingw-get install ...' again; it should now use the locally
  cached copies of the packages, without trying to download them again.

> This email and any attachments are confidential to the intended
> recipient and may also be privileged.  If you are not the intended
> recipient please delete it from your system and notify the sender.

Ha! Ha!  YOU'VE already broadcast it publicly to the World, his wife,
and everyone else and his dog.  How can it be confidential?

> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.

Too late for that!  It's already been publicly archived by umpteen
internet mail archive servers, for all the world to see, and for anyone
to do with as they wish, whether you like it or not.

Seriously, if you can't stop your e-mail conduit from inserting such
assinine, and utterly unenforceable disclaimers, then please find a
better e-mail conduit.

-- 
Regards,
Keith.

> So resorting to a manual install and totally daunted by the numbers of
> versions and, i.e. i would like msys1.0.16 with openssl which seems to
> only be made for msys1.0.13, other packages dont have any reliance of
> the msys release.

You can download an almost complete set of updated files (with working OpenSSL) from Mingw-w64 project. However, it doesn't seem to have any development tools for MSYS. Here's a link:

http://downloads.sourceforge.net/project/mingw-w64/External%20binary%20packages%20%28Win64%20hosted%29/MSYS%20%2832-bit%29/MSYS-20110309.zip

Dear MSYS developers users,
 
I use MSYS everyday as a shell for using my Windows box,
I also have developed a set of makefiles that allow me to use the Visual
Studio compilers from standrad unix makefile system.
 
I have come to update MSYS and can nolonger find my way around the
install process, ( alright i am dumb etc ...).
I tried the automatic installer ( even though i did not want MINGW and
wanted more than a the base MSYS system),
however the installer did not work probably becuase i am using it from
behind a firewall and would normally need to supply a http-proxy to
other tools like wget.
 
So resorting to a manual install and totally daunted by the numbers of
versions and, i.e. i would like msys1.0.16 with openssl which seems to
only be made for msys1.0.13, other packages dont have any reliance of
the msys release.
 
Can someone indicate a way forward for me please ??
 
 
BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace
Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687 
 

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************