From: Алексей П. <al...@gm...> - 2013-06-06 20:18:00
|
Hi, everybody! I have work on creating MSYS2 based on latest Cygwin sources and now create archives with alpha version. Links: 32-bit: x32-msys2-alpha-20130607.7z<http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-alpha-20130607.7z/download> 64-bit: x64-msys2-alpha-20130607.7z<http://sourceforge.net/projects/msys2/files/Alpha-versions/64-bit/x64-msys2-alpha-20130607.7z/download> MSYS2 is still using Cygwin like posix paths with /cygdrive prefix. I would be happy if it can be tested by users who uses MSYS environment. Information about issues you can send to al...@gm... or in this thread. Regards, Alexey. |
From: Keith M. <kei...@us...> - 2013-06-06 21:06:39
|
On 06/06/13 21:17, Алексей Павлов wrote: > I have work on creating MSYS2 based on latest Cygwin sources and now create > archives with alpha version. Thanks for your work on this, Alexey. > Links: > 32-bit: x32-msys2-alpha-20130607.7z<http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-alpha-20130607.7z/download> > 64-bit: x64-msys2-alpha-20130607.7z<http://sourceforge.net/projects/msys2/files/Alpha-versions/64-bit/x64-msys2-alpha-20130607.7z/download> First comment: why yet another project fork, guaranteed to create confusion over whence support is to come? Second: if we are to ultimately distribute this from the MinGW project pages, then it needs to be packaged in a format which mingw-get can handle; unless you are planning to contribute a streaming decompression and extraction filter, to be incorporated into mingw-get, then that means a *tar* archive, optionally compressed with your choice of gzip, bzip2, lzma, or xz; .7z is *not* (currently) acceptable. > MSYS2 is still using Cygwin like posix paths with /cygdrive prefix. This needs to change, preferably sooner, rather than later; the /cygdrive prefix needs to disappear. > I would be happy if it can be tested by users who uses MSYS environment. Sorry, but I won't be helping with this, primarily because my main development environment is hosted on GNU/Linux, using cross compilers for Windows code; a secondary issue for me is that, when I do resort to using MSYS, I expect to be able to manage the installation with mingw-get, and your .7z archive format precludes this. -- Regards, Keith. |
From: Алексей П. <al...@gm...> - 2013-06-07 04:21:10
|
2013/6/7 Keith Marshall <kei...@us...> > On 06/06/13 21:17, Алексей Павлов wrote: > > I have work on creating MSYS2 based on latest Cygwin sources and now > create > > archives with alpha version. > > Thanks for your work on this, Alexey. > > > Links: > > 32-bit: x32-msys2-alpha-20130607.7z< > http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-alpha-20130607.7z/download > > > > 64-bit: x64-msys2-alpha-20130607.7z< > http://sourceforge.net/projects/msys2/files/Alpha-versions/64-bit/x64-msys2-alpha-20130607.7z/download > > > > First comment: why yet another project fork, guaranteed to create > confusion over whence support is to come? > > MSYS2 as Cygwin use mingw-w64 runtime because original mingw-runtime don't suitable for it now. Mingw.org still doesn't have working 64-bit runtime but very big number of users has 64-bit systems. 64-bit MSYS2 work more faster on 64-bit OS than 32-bit MSYS2 on 64-bit OS. This is my opinion. I want ask here about porting MSYS2 to original mingw-runtime. Is anybody has time and wishes for it? I don't. I create MSYS2 project on sf.net to have MSYS2 worked on mingw-w64 runtime. When you guys want to port MSYS2 to original mingw runtime you can do it! > Second: if we are to ultimately distribute this from the MinGW project > pages, then it needs to be packaged in a format which mingw-get can > handle; unless you are planning to contribute a streaming decompression > and extraction filter, to be incorporated into mingw-get, then that > means a *tar* archive, optionally compressed with your choice of gzip, > bzip2, lzma, or xz; .7z is *not* (currently) acceptable. > > This is my alpha version only for test. And I don't see anything criminal in 7z format for it. MSYS2 contains p7zip to work with 7z archives. > > MSYS2 is still using Cygwin like posix paths with /cygdrive prefix. > > This needs to change, preferably sooner, rather than later; the > /cygdrive prefix needs to disappear. > > I work on it. > > I would be happy if it can be tested by users who uses MSYS environment. > > Sorry, but I won't be helping with this, primarily because my main > development environment is hosted on GNU/Linux, using cross compilers > for Windows code; a secondary issue for me is that, when I do resort to > using MSYS, I expect to be able to manage the installation with > mingw-get, and your .7z archive format precludes this. > > Ok. |
From: Earnie B. <ea...@us...> - 2013-06-07 14:58:06
|
On Fri, Jun 7, 2013 at 12:21 AM, Алексей Павлов wrote: > MSYS2 as Cygwin use mingw-w64 runtime because original mingw-runtime don't > suitable for it now. But it will eventually. The premise of your working on MSYS2 with mingw-w64 is just to allow us to get there faster. > This is my alpha version only for test. And I don't see anything criminal in > 7z format for it. MSYS2 contains p7zip to work with 7z archives. That's a chicken before the egg thing. I can't have eggs before I have a chicken and in this case the egg is p7zip and the chicken is MSYS2. I would prefer xz or lzma so that at least we have a method without installing some other package. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Eli Z. <el...@gn...> - 2013-06-07 07:03:57
|
> Date: Fri, 7 Jun 2013 08:21:02 +0400 > From: Алексей Павлов <al...@gm...> > > I don't see anything criminal in 7z format for it. 7z isn't Free Software ("free" as in "free speech"). It's not a crime using non-free software, but I'm quite sure Free Software is preferred around here. > MSYS2 contains p7zip to work with 7z archives. If you use a latest 7z, p7zip will not be able to unpack the archive. Even bsdtar (from libarchive) cannot open them yet. So using 7z will be a hassle for some users. Thanks. |
From: Алексей П. <al...@gm...> - 2013-06-07 07:12:25
|
2013/6/7 Eli Zaretskii <el...@gn...> > > Date: Fri, 7 Jun 2013 08:21:02 +0400 > > From: Алексей Павлов <al...@gm...> > > > > I don't see anything criminal in 7z format for it. > > 7z isn't Free Software ("free" as in "free speech"). It's not a crime > using non-free software, but I'm quite sure Free Software is preferred > around here. > > Ok. Not a problem) > > MSYS2 contains p7zip to work with 7z archives. > > If you use a latest 7z, p7zip will not be able to unpack the archive. > Even bsdtar (from libarchive) cannot open them yet. So using 7z will > be a hassle for some users. > > I'm using 7zip-9.20 because with latest versions I have troubles many times. But ok next snapshot I will do with tar or xz |
From: Pau G. i Q. <pgq...@el...> - 2013-06-07 16:48:49
|
On Fri, Jun 7, 2013 at 9:02 AM, Eli Zaretskii <el...@gn...> wrote: > Date: Fri, 7 Jun 2013 08:21:02 +0400 > > From: Алексей Павлов <al...@gm...> > > > > I don't see anything criminal in 7z format for it. > > 7z isn't Free Software ("free" as in "free speech"). It's not a crime > using non-free software, but I'm quite sure Free Software is preferred > around here. > Huh? According to its website and Wikipedia, the 7z format and the 7-zip tool are LGPL http://en.wikipedia.org/wiki/7z Or maybe there is something I don't know? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) |
From: Keith M. <kei...@us...> - 2013-06-07 08:12:25
|
On 7 June 2013 05:21, Алексей Павлов wrote: > MSYS2 as Cygwin use mingw-w64 runtime because original mingw-runtime don't > suitable for it now. Mingw.org still doesn't have working 64-bit runtime > but very big number of users has 64-bit systems. 64-bit MSYS2 work more > faster on 64-bit OS than 32-bit MSYS2 on 64-bit OS. This is my opinion. > > I want ask here about porting MSYS2 to original mingw-runtime. ... > Huh? Now I'm completely confused. MSYS-1.0 does not use, and never has used, the mingw-runtime; it has *always* used a derivative of newlib. MSYS-2 should do likewise. Any dependency on mingw-runtime, whether it might be ours, or that from mingw-w64, is just plain *wrong*. -- Regards, Keith. |
From: Peter R. <pe...@ly...> - 2013-06-07 08:35:04
|
On 2013-06-07 10:12, Keith Marshall wrote: > On 7 June 2013 05:21, Алексей Павлов wrote: > > MSYS2 as Cygwin use mingw-w64 runtime because original mingw-runtime don't suitable for it now. Mingw.org still doesn't have working 64-bit runtime but very big number of users has 64-bit systems. 64-bit MSYS2 work more faster on 64-bit OS than 32-bit MSYS2 on 64-bit OS. This is my opinion. > > I want ask here about porting MSYS2 to original mingw-runtime. ... > > > Huh? Now I'm completely confused. MSYS-1.0 does not use, and never has > used, the mingw-runtime; it has *always* used a derivative of newlib. > MSYS-2 should do likewise. Any dependency on mingw-runtime, whether it > might be ours, or that from mingw-w64, is just plain *wrong*. He's surely referring to the Win32 headers from mingw-w64. Cheers, Peter |
From: Алексей П. <al...@gm...> - 2013-06-07 09:09:02
|
2013/6/7 Peter Rosin <pe...@ly...> > On 2013-06-07 10:12, Keith Marshall wrote: > > On 7 June 2013 05:21, Алексей Павлов wrote: > > > > MSYS2 as Cygwin use mingw-w64 runtime because original mingw-runtime > don't suitable for it now. Mingw.org still doesn't have working 64-bit > runtime but very big number of users has 64-bit systems. 64-bit MSYS2 work > more faster on 64-bit OS than 32-bit MSYS2 on 64-bit OS. This is my opinion. > > > > I want ask here about porting MSYS2 to original mingw-runtime. ... > > > > > > Huh? Now I'm completely confused. MSYS-1.0 does not use, and never has > > used, the mingw-runtime; it has *always* used a derivative of newlib. > > MSYS-2 should do likewise. Any dependency on mingw-runtime, whether it > > might be ours, or that from mingw-w64, is just plain *wrong*. > > He's surely referring to the Win32 headers from mingw-w64. > > Cheers, > Peter > Yes. Sorry I mean Win32 API not all mingw runtime. |
From: Eli Z. <el...@gn...> - 2013-06-07 09:39:54
|
> Date: Fri, 7 Jun 2013 11:12:17 +0400 > From: Алексей Павлов <al...@gm...> > > next snapshot I will do with tar or xz Thanks. Another alternative is to use bsdtar. You can find its MinGW ports here: http://sourceforge.net/projects/mingw/files/MinGW/Extension/libarchive/libarchive-2.8.3-1/bsdtar-2.8.3-1-mingw32-bin.tar.bz2/download http://sourceforge.net/projects/ezwinports/files/libarchive-3.0.3-w32-bin.zip/download The advantage of using bsdtar is that it does the compression internally, so no need for external xz programs etc. |
From: Eli Z. <el...@gn...> - 2013-06-08 03:57:03
|
> From: Pau Garcia i Quiles <pgq...@el...> > Date: Fri, 7 Jun 2013 18:48:22 +0200 > > On Fri, Jun 7, 2013 at 9:02 AM, Eli Zaretskii <el...@gn...> wrote: > > > Date: Fri, 7 Jun 2013 08:21:02 +0400 > > > From: Алексей Павлов <al...@gm...> > > > > > > I don't see anything criminal in 7z format for it. > > > > 7z isn't Free Software ("free" as in "free speech"). It's not a crime > > using non-free software, but I'm quite sure Free Software is preferred > > around here. > > > > Huh? According to its website and Wikipedia, the 7z format and the 7-zip > tool are LGPL > > http://en.wikipedia.org/wiki/7z > > Or maybe there is something I don't know? First, I didn't say the format wasn't free, I only said that about 7z the program. Its home page (http://www.7-zip.org/) clearly says: 7-Zip is open source software. Most of the source code is under the GNU LGPL license. The unRAR code is under a mixed license: GNU LGPL + unRAR restrictions. And the license (http://www.7-zip.org/license.txt) includes these restrictions: unRAR restriction ----------------- The decompression engine for RAR archives was developed using source code of unRAR program. All copyrights to original unRAR code are owned by Alexander Roshal. The license for original unRAR code has the following restriction: The unRAR sources cannot be used to re-create the RAR compression algorithm, which is proprietary. Distribution of modified unRAR sources in separate form or as a part of other software is permitted, provided that it is clearly stated in the documentation and source comments that the code may not be used to develop a RAR (WinRAR) compatible archiver. So no, this isn't Free Software. As for the format, all I said is that the latest versions of it can only be opened by 7z.exe itself, no other Free Software package known to me can do that. In particular, p7zip cannot open such archives. So, archives compressed with the latest versions of 7z.exe will be unusable for those who don't want to use 7z.exe. |
From: Алексей П. <al...@gm...> - 2013-06-10 19:00:17
|
New snapshots released. In this version I split MSYS2 into two parts: MSYS2 (for using with mingw compilers) and DEVELOP (msys-gcc, msys-binutils, win32api, libraries, headers). Links: 32 bit: x32-msys2-alpha-20130610.tar.xz<http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-alpha-20130610.tar.xz/download> 32 bit develop: x32-msys2-alpha-20130610-develop.tar.xz<http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-alpha-20130610-develop.tar.xz/download> 64 bit: x64-msys2-alpha-20130610.tar.xz<http://sourceforge.net/projects/msys2/files/Alpha-versions/64-bit/x64-msys2-alpha-20130610.tar.xz/download> 64 bit develop: x64-msys2-alpha-20130610-develop.tar.xz<http://sourceforge.net/projects/msys2/files/Alpha-versions/64-bit/x64-msys2-alpha-20130610-develop.tar.xz/download> This snapshots resolve problems with trailing "/r" symbols when using mingw compilers. Perl rebuilded with new patch and now it show that it builded for msys. Also this snapshots fix issue: https://sourceforge.net/p/mingw/bugs/1963/ Regards, Alexey. |
From: George K. <xke...@ne...> - 2013-06-12 22:34:54
|
I downloaded x64-msys2-alpha-20130610.tar.xz and extracted it to C:\Users\Kernigh\Documents\cross64\ I run 64-bit Windows 7. The good part: MSYS2 has newer versions of many programs. awk 3.1.7 => 4.0.2 bash 3.1.17(1) => 4.2.45(4) coreutils 5.97 => 8.15 file 5.04 => 5.13 perl 5.8.8 => 5.14.4 It has new stuff. git 1.8.2.3 (good! I like git) svn 1.7.10 It no longer has cvs, but I no longer need cvs. MSYS2 has man and info! This is very welcome, I can now read "man bash" and "info coreutils". Without man and info, I would need to open a web browser and find manuals on the internet. The bad part: it has python and mercurial, but they are broken! $ python sh: /usr/bin/python: cannot execute binary file $ python2.7 Traceback (most recent call last): File "/usr/lib/python2.7/site.py", line 563, in <module> main() File "/usr/lib/python2.7/site.py", line 545, in main known_paths = addusersitepackages(known_paths) File "/usr/lib/python2.7/site.py", line 278, in addusersitepackages user_site = getusersitepackages() File "/usr/lib/python2.7/site.py", line 253, in getusersitepackages user_base = getuserbase() # this will also set USER_BASE File "/usr/lib/python2.7/site.py", line 243, in getuserbase USER_BASE = get_config_var('userbase') File "/usr/lib/python2.7/sysconfig.py", line 521, in get_config_var return get_config_vars().get(name) File "/usr/lib/python2.7/sysconfig.py", line 420, in get_config_vars _init_posix(_CONFIG_VARS) File "/usr/lib/python2.7/sysconfig.py", line 299, in _init_posix raise IOError(msg) IOError: invalid Python installation: unable to open /usr/include/python2.7/pyconfig.h (No such file or directory) $ hg /usr/bin/hg: line 10: import: command not found /usr/bin/hg: line 11: import: command not found /usr/bin/hg: line 13: libdir: command not found /usr/bin/hg: line 16: syntax error near unexpected token `(' /usr/bin/hg: line 16: ` if not os.path.isabs(libdir):' There is both mingw_shell.bat and msys2_shell.bat. What is the difference? They seem to act the same, so why not have just one msys.bat like in the old MSYS? Whenever I start MSYS2, it complains, "The /etc/passwd (and possibly /etc/group) files should be rebuilt." This is a regression, because the old MSYS works without /etc/passwd or /etc/group. It also says, "See the man pages for mkpasswd and mkgroup". Those commands exist, but they have no manual entries. I am ignoring this message and using MSYS2 without any /etc/passwd or /etc/group files. The first run put .bash_profile, .bashrc, .inputrc and .profile into my new home directory. I don't like the existence of .bash_profile; I would prefer that bash use .profile instead. I don't understand why .profile sets LANG but .bash_profile does not. (Because the .bat file runs bash as 'sh', it does actually use .profile and set LANG.) The info directory node is corrupt. When I run "info", I see a bunch of question marks, and one entry for nettle. There are no entries for bash or coreutils, but running "info bash" or "info coreutils" does work. To use gcc, I must run $ mount C:/MinGW /mingw mount: warning - /mingw does not exist. $ PATH=/mingw/bin:$PATH I hope to upgrade to MSYS2 in the future. --George Koehler |
From: Keith M. <kei...@us...> - 2013-06-13 07:06:34
|
On 12/06/13 23:34, George Koehler wrote: > It has new stuff. > git 1.8.2.3 (good! I like git) I don't! I use it, under protest, when absolutely necessary. Each to his own; mercurial is much nicer, and hg-git makes git bearable. :) > svn 1.7.10 I don't use SVN, but I'm sure some will welcome its availability. > It no longer has cvs, but I no longer need cvs. I don't use it much, any more, but I do have the occasional need of it. MSYS-1 has it, and retaining legacy support is, IMO, imperative. This omission is BAD! > MSYS2 has man and info! This is very welcome, I can now read "man bash" > and "info coreutils". Without man and info, I would need to open a web > browser and find manuals on the internet. MSYS-1 has had info just about forever, and man was added several years ago; this implied criticism is unwarranted. > The bad part: it has python and mercurial, but they are broken! I don't need python directly, but I do use mercurial. The stock distribution from http://mercurial.selenic.com/ includes the necessary python libraries, and works just fine with MSYS-1. Given this, I don't understand why we, as MinGW.org would want to burden ourselves with maintaining a separate fork for MSYS-2. > The info directory node is corrupt. The info directory file should not be shipped; it should be built dynamically, as individual packages are installed. Can you rebuild it by running install-info? If not, please file a bug against MSYS-2's install-info implementation. -- Regards, Keith. |
From: Алексей П. <al...@gm...> - 2013-06-13 07:22:42
|
2013/6/13 Keith Marshall <kei...@us...>: > On 12/06/13 23:34, George Koehler wrote: >> It has new stuff. >> git 1.8.2.3 (good! I like git) > > I don't! I use it, under protest, when absolutely necessary. Each to > his own; mercurial is much nicer, and hg-git makes git bearable. :) > It can be optional package in "MSYS2" distro. You can have your opinion but users have their own. >> svn 1.7.10 > > I don't use SVN, but I'm sure some will welcome its availability. > >> It no longer has cvs, but I no longer need cvs. > > I don't use it much, any more, but I do have the occasional need of it. > MSYS-1 has it, and retaining legacy support is, IMO, imperative. This > omission is BAD! > >> MSYS2 has man and info! This is very welcome, I can now read "man bash" >> and "info coreutils". Without man and info, I would need to open a web >> browser and find manuals on the internet. > > MSYS-1 has had info just about forever, and man was added several years > ago; this implied criticism is unwarranted. > >> The bad part: it has python and mercurial, but they are broken! Try to download develop archive and copy /include/python2.7 folder from it to <msys_root>/include folder. Then python works well. > > I don't need python directly, but I do use mercurial. The stock > distribution from http://mercurial.selenic.com/ includes the necessary > python libraries, and works just fine with MSYS-1. Given this, I don't > understand why we, as MinGW.org would want to burden ourselves with > maintaining a separate fork for MSYS-2. If you read mingw-w64 ML's you can see our hot discussion with Corinna about forking Cygwin. I think in near future all MSYS functionality will be added to Cygwin sources directly and we don't need anymore to create MSYS. > >> The info directory node is corrupt. Yes It corrupted. > > The info directory file should not be shipped; it should be built > dynamically, as individual packages are installed. Can you rebuild it > by running install-info? If not, please file a bug against MSYS-2's > install-info implementation. > > -- > Regards, > Keith. > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe |
From: Keith M. <kei...@us...> - 2013-06-13 08:10:14
|
On 13 June 2013 08:22, Алексей Павлов wrote: > 2013/6/13 Keith Marshall <em...@ad...m>: > Please don't feed the spammers; adjust your mailer to elide addresses. > > On 12/06/13 23:34, George Koehler wrote: > >> It has new stuff. > >> git 1.8.2.3 (good! I like git) > > > > I don't! I use it, under protest, when absolutely necessary. Each to > > his own; mercurial is much nicer, and hg-git makes git bearable. :) > > > > It can be optional package in "MSYS2" distro. There's no question of "can be"; for a MinGW.org distribution, it MUST be. > You can have your opinion but users have their own. > Of course. That's exactly what "each to his own" means. There's absolutely no suggestion, not even implied, that we shouldn't offer the option. > >> The info directory node is corrupt. > > Yes It corrupted. > But why is it distributed, at all? It should be BUILT, post-install... > > The info directory file should not be shipped; it should be built > > dynamically, as individual packages are installed. Can you rebuild it > > by running install-info? If not, please file a bug against MSYS-2's > > install-info implementation. > -- Regards, Keith. |
From: Eli Z. <el...@gn...> - 2013-06-13 12:54:47
|
> Date: Thu, 13 Jun 2013 08:06:22 +0100 > From: Keith Marshall <kei...@us...> > > > It no longer has cvs, but I no longer need cvs. > > I don't use it much, any more, but I do have the occasional need of it. > MSYS-1 has it, and retaining legacy support is, IMO, imperative. This > omission is BAD! I agree. For example, building GNU Make out of its git repository requires to fetch GNU Coding Standards Texinfo sources using CVS. You simply cannot build Make out of git without that. |
From: Alexey P. <al...@gm...> - 2013-06-25 14:53:44
|
I upload new snapshots for testing: 32-bit: x32-msys2-alpha-20130625.tar.xz<http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-alpha-20130625.tar.xz/download> 64-bit: x64-msys2-alpha-20130625.tar.xz<http://sourceforge.net/projects/msys2/files/Alpha-versions/64-bit/x64-msys2-alpha-20130625.tar.xz/download> Regards, Alexey. |