Trouble installing a new version of MSYS.

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

_______________________________________________
Mingw-msys mailing list
Mingw-msys@...
https://lists.sourceforge.net/lists/listinfo/mingw-msys

Re: Trouble installing a new version of MSYS.

> 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

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

Re: Trouble installing a new version of MSYS.

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.

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

PATH in MSYS

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

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

Re: PATH in MSYS

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.

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

Updated: vim-7.3-1

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=/ \
--with-compiledby=ir0nh34d@... \
--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

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

Re: Updated: vim-7.3-1

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

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

Re: Updated: vim-7.3-1

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

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

Re: Updated: vim-7.3-1

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

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

Re: Updated: vim-7.3-1

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

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d