Re: [Mingw-w64-public] [ANN] Website changes

[Stephen Kitt]

Hi Adrien,

On Mon, 30 Mar 2015 22:49:27 +0200, Adrien Nader  wrote:
[...]
> 
> Thanks for the list.
> 
> Can you check the information is correct?
> I've not added a line for debian experimental since it's expiremental
> and changes quite often: it needs someone actively updating the page.

Excellent, thanks! Everything seems OK to me. You're right about the
experimental info...

> I'll ping you when the user registration stuff is fixed if you want.

... and that sounds like a great idea too.

> On a related note, I'll try to spend time next week-end to improve the
> layout of the tables a bit as they'd probably benefit from cell borders
> (I find them a bit difficult to read at times with their current style).

That would improve the readability of merged cells in particular!

Regards,

Stephen

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] sbuild update - 6.0

[LRN]

On 31.03.2015 4:08, David Macek wrote:
> On 30. 3. 2015 20:22, LRN wrote:
>> A python2-utf8.sh startup script in /etc/profile.d forces Python to use UTF-8
>> encoding. I'm still unsure whether this will have any adverse effects. A
>> matching change to console codepage (chcp 65001) was planned, but was 
>> disabled
>> at the last moment, since it caused Python to error-out on write() to 
>> console.
> 
> Have you tried setting PYTHONIOENCODING?

This is exactly how it forces Python to use UTF-8.

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org


0x922360B0.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] sbuild update - 6.0

[David Macek]

Hi.

On 30. 3. 2015 20:22, LRN wrote:
> A python2-utf8.sh startup script in /etc/profile.d forces Python to use UTF-8
> encoding. I'm still unsure whether this will have any adverse effects. A
> matching change to console codepage (chcp 65001) was planned, but was disabled
> at the last moment, since it caused Python to error-out on write() to console.

Have you tried setting PYTHONIOENCODING? 


-- 
David Macek



smime.p7s
Description: S/MIME Cryptographic Signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [ANN] Website changes

[Adrien Nader]

Hi,

On Sun, Mar 29, 2015, Stephen Kitt wrote:
> Hi,
> 
> On Tue, 24 Mar 2015 21:20:04 +0100, Adrien Nader  wrote:
> [...]
> > There's an additional reason: I'm seeing cygwin similarly to
> > fedora/opensuse/arch.
> > If someone is already using these, the entries on the website will make
> > him check his version requirements and look at his distro package
> > manager. They probably won't make anyone start using these distros
> > however. Some distros have recent versions, some don't (debian, ubuntu)
> > and I believe this page can help the user by providing something simple
> > to read.
> [...]
> 
> Would it actually be possible to mention the Debian and Ubuntu toolchains on
> the download page? Most people find MinGW-w64 via the MinGW-w64 web site
> rather than via their distribution, and I regularly get emails from people
> surprised to find out that the toolchain is packaged in Debian/Ubuntu: since
> it's not mentioned on the MinGW-w64 website they figure that their only
> solution is to download one of the Win-builds.
> 
> Anyway, we currently support:
> * Debian 7 (Wheezy): builds for i686, x86_64; gcc 4.6.3, MinGW-w64 2.0.3, with
>   C, C++, Fortran, Ada, Objective-C and Objective-C++ compilers; C11/C++11
>   threading isn't supported; the package manager is Apt/Dpkg; installation is
>   done within Debian (https://packages.debian.org/mingw-w64)
> * Debian 8 (Jessie): as above, with gcc 4.9.1, MinGW-w64 3.2.0; C11/C++11
>   threading is supported (a Win32 threading variant is also available)
> * Debian has MinGW-w64 4.0.1 in the experimental repositories
> * Ubuntu 12.04 (Precise Pangolin): as above, with gcc 4.6.3, MinGW-w64 2.0.1
>   (https://launchpad.net/ubuntu/+source/mingw-w64)
> * Ubuntu 14.04 (Trusty Tahr): as above, with gcc 4.8.2, MinGW-w64 3.1.0,
>   C11/C++11 threading (using winpthreads)
> * Ubuntu 14.10 (Utopic Unicorn): as above, with gcc 4.9.1, MinGW-w64 3.1.0,
>   C11/C++11 threading (a Win32 threading variant is also available)
> * Ubuntu 15.04 (Vivid Vervet): as above, with gcc 4.9.2, MinGW-w64 3.2.0
> 
> The only additional software currently available is gdb and nsis.

Thanks for the list.

Can you check the information is correct?
I've not added a line for debian experimental since it's expiremental
and changes quite often: it needs someone actively updating the page.
I'll ping you when the user registration stuff is fixed if you want.

On a related note, I'll try to spend time next week-end to improve the
layout of the tables a bit as they'd probably benefit from cell borders
(I find them a bit difficult to read at times with their current style).

-- 
Adrien Nader

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [ANN] Website changes

[Adrien Nader]

Hi,

On Sat, Mar 28, 2015, Jason Curl wrote:
> 
> On 20/03/2015 22:51, Adrien Nader wrote:
> > Any constructive criticism is welcome; don't hesitate.
> >
> Hi, on the page: http://mingw-w64.yaxm.org/doku.php/documentation
> the link to "libmangle" is broken. Clicking on it takes me here: 
> http://mingw-w64.yaxm.orglibmangle/

Thanks for the notice. This was due to an overly simple rewrite rule.
Libmangle's API documentation is still on sourceforge servers.
Note that since the redirects use the HTTP 301 code, your browser is
going to be a bit reticent to asking the server again for the actual
location of the page (i.e. clear your cache).

-- 
Adrien Nader

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] sbuild update - 6.0

[LRN]

S[mart|tupid] build[1] is updated to 6.0 [2]

= About =

sbuild is a set of scripts that build various free software packages for
Windows from the source, starting with a GCC toolchain (cross-compiled)
and MSYS2 core (cross-compiled), and ending with various applications
(msys2-git, msys2-subversion, mingw-gdb), libraries and frameworks
(GTK+, GNUnet, GStreamer). All buildscripts are written in
simple-to-understand-style of POSIX shell language, and a few small
utilities are in Python.

= Release Highlights =

== Migration to Launchpad ==

Since Gitorious is being closed down, i had to find new free software hosting
for this project. Launchpad turned out to be the only one still-alive free
AGPL-licensed hosting that would accept sbuild (Savannah is also alive, free
and AGPL, but they are rather picky, and i wasn't sure they'd let me host the
files there), so Launchpad it is. Sadly, this means migrating from git to bzr,
but at least i'll finally have an opportunity to try this VCS for real.
Hopefully, this won't be for long, as Launchpad may get[3] native git support
later.

A side-effect is that i've had to come to terms with the fact (which i was
aware of, but it was easy to disregard it until now) that "sbuild" is not a
unique name, so the Launchpad project is named StupidBuild.

== Cross-compilation script rework ==

MSYS2 and MinGW-w64 cross-compilation scripts were significantly rewritten. Now
both are written completely in Python (MSYS2 script was written in shell
before, and MinGW-w64 script was driven by a top-level shell script) and are
somewhat nicer.

One good side-effect is that now cross-compiled packages will have proper -bld
and -src packages and release notes - something that my MSYS2 cross-compiled
packages lacked.

== MSYS2 ==

Added a few packages that i thought useful:
procps - provides a souped-up version of the "ps" program that stock MSYS2 
lacks.
colordiff & dwdiff - provide colored diff and a (also colored, if needed)
word-based diff. I've supplied a "diffwc" script that adds a bit more colors to
the output of dwdiff and calls it with all the appropriate flags, piping the
output of an ordinary diff.

Due to some problems with Debian's mingw-w64 packages i had trouble updating
the W32API part of MSYS2 devfiles past the January 2015 version. The problems
are temporary and are expected to eventually go away as Debian updates its
mingw-w64 cross-compiler packages. For now there's a new feature in MSYS2
cross-compilation script to use the cross-compiler built by the MinGW branch of
sbuild instead of the cross-compiler provided by Debian.

Cross-compiled parts had massive version bumps all over the place, including
newer bash, binutils, gcc, ca-certificates, gettext, ncurses and openssl.

xz was not updated because of some incompatibilities with Cygwin. I've read
that these were recently fixed, but this sbuild update was delayed for too long
already, so newer xz will have to wait until next time.

I've added some file list checks to the packing parts of the scripts, so now
the list of installed files staged for packing is compared to the list of files
actually packed. This allowed me to learn exactly which files were omitted and
which files were packed twice (in different packages). That led to a few
packaging bugs being fixed.

igncr shell option is no longer enabled by default. This affects both MSYS and
MinGW shell.

A python2-utf8.sh startup script in /etc/profile.d forces Python to use UTF-8
encoding. I'm still unsure whether this will have any adverse effects. A
matching change to console codepage (chcp 65001) was planned, but was disabled
at the last moment, since it caused Python to error-out on write() to console.

== MinGW ==

I *think* i've found the source of the strange bug in mercurial that caused it
to crash sporadically - the culprit seems to be the use of msvcr90 and msvcrt
in the same DLL. The only way to fix this was to hack on Python distutils.
Until now sbuild relied on upstream W32 CPython, with was tweaked a bit with a
few symlinks, import libraries and extra scripts, without changing Python
itself. This is no longer true. If Python purity is important, i would suggest
having a separate Python 2.7.x installation for sbuild use only.

Note that this still doesn't fix some of the problems that arise from mixing
msvcrXX and msvcrt. Namely, pyliblzma extension will segfault (presumably -
because it uses a file object from msvcr90 with msvcrt functions), and
mercurial will also segfault while trying to write into a file using a utility
extension written in C (which is why it's been patched to use pure-Python
version of that extension).

The toolchain saw some updates - minor version bumps on bintuils, gcc, and a
major one on mingw-w64 crt/headers (which is the reason why the update was
delayed for so long - i've been waiting for MinGW-w64 4.x to be released).

Bzr (and Cython as a prerequisite) was added. I think the only mainstream VCS
missing in sbuild now is CVS...