headers
Charles Wilson | 1 Sep 2010 01:00
Picon

Re: GCC 4.5 XML manifests for mingw-get

On 8/31/2010 6:26 PM, Charles Wilson wrote:
> On 8/31/2010 3:44 PM, Charles Wilson wrote:
>> Right.  I guess if I pre-populate my build dir with the .lzma files
>> from the web, then THOSE won't get updated (?)...but everything else
>> will get the current status.
>>
>> I'll give that a try tonight.
>
> This worked.  But... you and I are stepping on each other's toes
> *right now*.

OK, it all seems copacetic.  I've tested the installer using the .lzma
files that are currently on the web. Here it is:

http://mingw.cwilson.fastmail.fm/mingw-get-inst-20100831.exe

Give it 24 hours, and I'll upload it to mingw.org (and a snapshot of the
source code -- which is all of two files: the .iss and the .ico) unless
someone squawks.

I've put a date stamp on it (rather than a version number like
0.1-alpha-3), because as it is, it carries a snapshot of the xml
manifests downloaded -- via 'mingw-get update' as of today's date.

--
Chuck

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Cesar Strauss | 1 Sep 2010 05:41
Picon

Re: GCC 4.5 XML manifests for mingw-get

On 31/8/2010 20:00, Charles Wilson wrote:
> OK, it all seems copacetic.  I've tested the installer using the .lzma
> files that are currently on the web. Here it is:
>
> http://mingw.cwilson.fastmail.fm/mingw-get-inst-20100831.exe

Working great, thanks!

> Give it 24 hours, and I'll upload it to mingw.org (and a snapshot of the
> source code -- which is all of two files: the .iss and the .ico) unless
> someone squawks.
>
> I've put a date stamp on it (rather than a version number like
> 0.1-alpha-3), because as it is, it carries a snapshot of the xml
> manifests downloaded -- via 'mingw-get update' as of today's date.
>

If I may make a suggestion, you do not need to ship in the installer any 
manifest besides default.xml or profile.xml. Currently, mingw-get will 
fetch any missing manifest automatically, even as it fulfills the 
install request.

To test this, I rebuilt the installer without the manifests, and it 
worked fine (it downloaded all the missing manifests before proceeding 
with the installation).

The benefit is, you get the most up-to-date packages at the time of 
installation, without needing to keep rebuilding the installer every 
time a manifest is updated.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Charles Wilson | 1 Sep 2010 05:56
Picon

Re: GCC 4.5 XML manifests for mingw-get

On 8/31/2010 11:41 PM, Cesar Strauss wrote:
> On 31/8/2010 20:00, Charles Wilson wrote:
>> http://mingw.cwilson.fastmail.fm/mingw-get-inst-20100831.exe
> 
> Working great, thanks!
> 
> If I may make a suggestion, you do not need to ship in the installer any 
> manifest besides default.xml or profile.xml.
...
> The benefit is, you get the most up-to-date packages at the time of 
> installation, without needing to keep rebuilding the installer every 
> time a manifest is updated.

I did it this way, for THIS release, deliberately.  I wanted it to
install a "snapshot" specifically so that I knew it was fully tested and
that future changes to the website wouldn't break it: e.g. if we upload
a bogus .xml.lzma or something.

I'm being very conservative because mingw-get is so new, AND because
Keith will be awol for about six-eight weeks.

Once this one is out there and percolating, then I reckon the NEXT
release should do something like you suggest.  That one won't have a
datestamp, but would instead carry mingw-get's own version number.

Plus, the installation just created could always be updated by manually
running 'mingw-get update; mingw-get install ...'

--
Chuck
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hin-Tak Leung | 1 Sep 2010 07:00
Picon
Favicon

Re: msys-flex on vista: fatal internal error, exec failed

Keith Marshall wrote:
> I'm fairly certain this used to work on the old Win2K box, but since 
> my company's IT department decided we should all upgrade to vista, I'm 
> seeing this for all attempts to run flex, with any valid input, e.g.:
> 
>   $ flex /e/tmp/pkginfo.l
>   flex: fatal internal error, exec failed
> 
> The result is the same, with both available MSYS builds of flex-2.35.
> Everything else in the MSYS tree is bang up to date, per the msys-base 
> manifests we published for mingw-get, just a few weeks ago, and this is 
> the first mysterious failure I've experienced.
> 
> Anyone else able to reproduce this?  Any ideas how I might set about 
> tracking down the problem?

Possibly UAC related? Vista and Windows 7 have some strange ideas about 
permissions regarding writing to current directory (desktop) as well as creation 
of temporary files (which often happens to be C:/windows/temp or thereabouts).

I'd look for where temp files are written first.

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
Permalink | Reply | 0 comments |
headers
NightStrike | 1 Sep 2010 06:17
Picon

Re: msys-flex on vista: fatal internal error, exec failed

On Tue, Aug 31, 2010 at 9:00 AM, Keith Marshall
<keithmarshall@...> wrote:
> I'm fairly certain this used to work on the old Win2K box, but since
> my company's IT department decided we should all upgrade to vista, I'm
> seeing this for all attempts to run flex, with any valid input, e.g.:
>
>  $ flex /e/tmp/pkginfo.l
>  flex: fatal internal error, exec failed
>
> The result is the same, with both available MSYS builds of flex-2.35.
> Everything else in the MSYS tree is bang up to date, per the msys-base
> manifests we published for mingw-get, just a few weeks ago, and this is
> the first mysterious failure I've experienced.
>
> Anyone else able to reproduce this?  Any ideas how I might set about
> tracking down the problem?

What's the value of your M4 env var?  flex tries to exec m4.  I think.

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
Permalink | Reply | 1 comment |
headers
Keith Marshall | 1 Sep 2010 11:44
Picon

Re: msys-flex on vista: fatal internal error, exec failed

On 01/09/2010, NightStrike <nightstrike@...> wrote:
> On Tue, Aug 31, 2010 at 9:00 AM, Keith Marshall
> <keithmarshall@...> wrote:
>> I'm fairly certain this used to work on the old Win2K box, but since
>> my company's IT department decided we should all upgrade to vista, I'm
>> seeing this for all attempts to run flex, with any valid input, e.g.:
>>
>>  $ flex /e/tmp/pkginfo.l
>>  flex: fatal internal error, exec failed
>
> What's the value of your M4 env var?  flex tries to exec m4.  I think.

Thanks.  You think a-right; that's pointed me in the right direction.

I don't have an M4 env var, and never needed one.  I still don't; I simply
didn't have m4 installed.  Installing it was all that was required; shame
the error message wasn't more explicit about *what* it failed to exec!

I'll add the missing dependency to my copy of the mingw-get manifest for
msys-flex-bin, (already differs from CVS), commit and publish it tonight.

--

-- 
Regards,
Keith.

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Keith Marshall | 1 Sep 2010 15:11
Picon

Re: GCC 4.5 XML manifests for mingw-get

On Tuesday 31 August 2010 20:44:59 Charles Wilson wrote:
> > ... what you really mean is that you are missing a step to
> > synchronise between the state represented by issue.log, and the
> > content of your (initially empty of .lzma files) build directory.
> >  That's a piece of the jigsaw which I've yet to finalise.
>
> Right.  I guess if I pre-populate my build dir with the .lzma files
> from the web, then THOSE won't get updated (?)...but everything else
> will get the current status.

Yes, but that would be a kind of ungainly way to do it.

> I'll give that a try tonight.
>
> If it works, ...

You later confirmed that it does.

> ... then the jigsaw might be as simple as a rule which does 
> exactly that: if the target .lzma doesn't exist, check to see if a
> copy can be downloaded first.  Then, compare the uncompressed copy
> with the src copy (excluding the serialization strings themselves)...
>
> Ugh. This is ugly.
>
> I wonder if 'make' is the right tool for this job, ...

IMO yes, make is exactly the right tool for this job.

> ... or if we need a manifest-maint.exe tool.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christopher Faylor | 8 Sep 2010 02:24

Re: Fw: Goodbye

On Wed, Aug 25, 2010 at 10:27:49PM -0400, Charles Wilson wrote:
>On 8/25/2010 5:42 PM, Danny Smith wrote:
>> I have not been active as port maintainer for a long time. Kai and
>> Dave are doing a very good job.
>> Thanks for all your help.
>
>Thanks for all you've done over the years, Danny -- mingw would not be
>what it is without your efforts.  I'm sorry to see you go -- hopefully
>you'll stick around enough to play "wise elder statesman" if needed!

I just saw this message.  Ditto!

Danny, it has always been a pleasure working with you.  Best of luck
and thanks for all the considerable effort you've put into making this
stuff better.

cgf

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
Permalink | Reply | 0 comments |
headers
Chris Sutcliffe | 8 Sep 2010 15:31
Picon

gdb-7.2

Hi All,

I've packaged gdb 7.2 but I have 2 different binaries and I'm curious
how best to package it.  Basically I have one gdb.exe that is python
enabled (linked against python27.dll) and one that is not.  I'm
wondering if I should create 2 'bin' packages (one python, one not),
or one 'bin' package with gdb.exe and gdb-python.exe.

Thoughts?

Chris

--

-- 
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
Permalink | Reply | 4 comments |
headers
Charles Wilson | 8 Sep 2010 15:35
Picon

Re: gdb-7.2

On 9/8/2010 9:31 AM, Chris Sutcliffe wrote:
> I've packaged gdb 7.2 but I have 2 different binaries and I'm curious
> how best to package it.  Basically I have one gdb.exe that is python
> enabled (linked against python27.dll) and one that is not.  I'm
> wondering if I should create 2 'bin' packages (one python, one not),
> or one 'bin' package with gdb.exe and gdb-python.exe.

My personal opinion is to package it in a single gdb pkg -- with lots of
explanation in the RELEASE_NOTES file.

--
Chuck

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
Permalink | Reply | 3 comments |

Gmane