headers
Dean Scarff | 1 Jul 2009 03:01
Picon
Gravatar

[RFU 1.7] nasm-2.06-1

Upstream release.

Built for cygwin 1.7.

There are a couple of relevant packaging conventions that I've noticed
discussed on this list and in practice that contradict
http://cygwin.com/setup.html yet haven't had an official response (at
least I can't find it in the archives).

 - should setup.hint have requires: cygwin?  nasm's does.
 - should it be /usr/share/doc/nasm or /usr/share/doc/nasm-2.06? nasm's
   is the former

I forgot to announce the 2.05-1 package so I'll just announce this one
once it hits the mirrors, assuming above issues aren't a problem.

wget \
'http://scarff.id.au/file/cygwin/nasm/nasm-2.06-1-src.tar.bz2' \
'http://scarff.id.au/file/cygwin/nasm/nasm-2.06-1.tar.bz2'
rm -f nasm-2.05-1-src.tar.bz2 nasm-2.05-1.tar.bz2

--

-- 
Dean
Permalink | Reply | 4 comments |
headers
Dave Korn | 1 Jul 2009 10:23

Re: [patch] Fix setup.exe chooser page header column borkage.

Christopher Faylor wrote:
> On Tue, Jun 30, 2009 at 06:15:58PM +0100, Dave Korn wrote:

>> [ Heh.  Legacy code FTW.  To me it looks like some of the code was
>> developed in parallel with some of the developers learning the ins and
>> outs of writing big C++ applications for the first time.  That's only
>> to be expected; there's a lot of stuff about a language that you just
>> don't learn until you really use it in anger for a while.  Anyway, it
>> is what it is and it's not _that_ bad.  ]
> 
> Actually, I don't think anyone who wrote this part of the code would
> claim to have been learning c++.

  It can be difficult to communicate clearly in email.  Before I wrote that
paragraph, it had a specific example, but then I took it out because it might
look unfairly critical of the specific individual who contributed it, which it
wasn't meant to be.  Unfortunately that left it ambiguously looking like I
might have been referring specifically to the code we're looking at now.  I
wasn't!

>>  Ok?
> 
> Looks ok to me.  Thanks for tracking this down.

  Pleasure, it's been nagging at me for a while.  Hooray for being unemployed
and actually having the spare time to spend on making things nice :)

    cheers,
      DaveK
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Korn | 1 Jul 2009 10:42

setup.exe CoCreateInstance error.


    Hi Corinna,

  I got this warning dialog during testing (w2k), after I updated to HEAD:

---------------------------
make_link_2
---------------------------
CoCreateInstance failed with error 80004002.
Setup will not be able to create Cygwin Icons
in the Start Menu or on the Desktop.
---------------------------
OK
---------------------------

  That's E_NOINTERFACE.  I checked the value of CLSID_ShellLink in the w32api
sources, and made sure that I appear to have the required registry key:

HKEY_CLASSES_ROOT\CLSID\{00021401-0000-0000-C000-000000000046}

  So it looks as if there may not even be any one place to call
CoCreateInstance from that works for both win7 and w2k.  Argh.  I had a quick
hack at it by trying to call CoCreateInstance again in make_link_2 if the 'sl'
pointer wasn't already set but it still failed (same error); maybe w2k just
isn't happy with having CoInit called so early.  I'm going to leave it for now
because I want to get on with the libstdcxx support respin, but I could do
some testing if you can think up a patch.

    cheers,
      DaveK
(Continue reading)

Permalink | Reply | 3 comments |
headers
Corinna Vinschen | 1 Jul 2009 12:52
Favicon

Re: [RFU 1.5 and 1.7] libaprutil1-1.3.7

On Jun 30 09:02, David Rothenberger wrote:
> On 6/30/2009 1:30 AM, Corinna Vinschen wrote:
>> Here, the aprutil1 package still exists in the 1.7 release area, but
>> I don't think it makes sense anymore, along the same lines as for
>> libapr1.  I think it should be ok to remove it from the 1.7 release.
>> What do you say?
>
> The aprutil1 and apr1 packages are just transition packages to help  
> people upgrade from the old package naming schema to the new one. They  
> don't need to be in the 1.7 area if we believe everyone will have  
> updated their apr1 and aprutil1 packages before they try to upgrade to  
> 1.7. I'm not sure that's true, though. It seems there are at least some  
> people that only update once every 3-5 years. :-)

So you'd rather have the apr1 package in the 1.7 release as well?

Corinna

--

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat
Permalink | Reply | 4 comments |
headers
Corinna Vinschen | 1 Jul 2009 12:58
Favicon

Re: [RFU 1.7] nasm-2.06-1

On Jul  1 09:01, Dean Scarff wrote:
> Upstream release.
> 
> Built for cygwin 1.7.
> 
> There are a couple of relevant packaging conventions that I've noticed
> discussed on this list and in practice that contradict
> http://cygwin.com/setup.html yet haven't had an official response (at
> least I can't find it in the archives).
> 
>  - should setup.hint have requires: cygwin?  nasm's does.
>  - should it be /usr/share/doc/nasm or /usr/share/doc/nasm-2.06? nasm's
>    is the former

Every package seems to have its own idea how to name the doc dir.  It's
not *that* important.  I guess the better approach is to omit the
version.  After all, you usually have just one of the packages installed
and the user doesn't exactly care for the actual version of the package
when looking for the docs.

> I forgot to announce the 2.05-1 package so I'll just announce this one
> once it hits the mirrors, assuming above issues aren't a problem.
> 
> wget \
> 'http://scarff.id.au/file/cygwin/nasm/nasm-2.06-1-src.tar.bz2' \
> 'http://scarff.id.au/file/cygwin/nasm/nasm-2.06-1.tar.bz2'
> rm -f nasm-2.05-1-src.tar.bz2 nasm-2.05-1.tar.bz2

Uploaded.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Dave Korn | 1 Jul 2009 13:17

Re: [RFU 1.7] nasm-2.06-1

Corinna Vinschen wrote:
> On Jul  1 09:01, Dean Scarff wrote:
>> Upstream release.
>>
>> Built for cygwin 1.7.
>>
>> There are a couple of relevant packaging conventions that I've noticed
>> discussed on this list and in practice that contradict
>> http://cygwin.com/setup.html yet haven't had an official response (at
>> least I can't find it in the archives).
>>
>>  - should setup.hint have requires: cygwin?  nasm's does.

  No, that's now an obsolete practice, it should be removed.  See e.g.:

http://cygwin.com/ml/cygwin-apps/2009-06/msg00145.html

>>  - should it be /usr/share/doc/nasm or /usr/share/doc/nasm-2.06? nasm's
>>    is the former
> 
> Every package seems to have its own idea how to name the doc dir.  It's
> not *that* important.  I guess the better approach is to omit the
> version.  After all, you usually have just one of the packages installed
> and the user doesn't exactly care for the actual version of the package
> when looking for the docs.

  Omitting the version number is the new convention; see the thread: "[RFC]
1.7 Packaging: Documentation":

http://www.cygwin.com/ml/cygwin-apps/2008-08/threads.html#00081
(Continue reading)

Permalink | Reply | 2 comments |
headers
Corinna Vinschen | 1 Jul 2009 13:28
Favicon

Re: setup.exe CoCreateInstance error.

Hi Dave,

On Jul  1 09:42, Dave Korn wrote:
> 
>     Hi Corinna,
> 
>   I got this warning dialog during testing (w2k), after I updated to HEAD:
> 
> ---------------------------
> make_link_2
> ---------------------------
> CoCreateInstance failed with error 80004002.
> Setup will not be able to create Cygwin Icons
> in the Start Menu or on the Desktop.
> ---------------------------
> OK
> ---------------------------
> 
>   That's E_NOINTERFACE.  I checked the value of CLSID_ShellLink in the w32api
> sources, and made sure that I appear to have the required registry key:
> 
> HKEY_CLASSES_ROOT\CLSID\{00021401-0000-0000-C000-000000000046}
> 
>   So it looks as if there may not even be any one place to call
> CoCreateInstance from that works for both win7 and w2k.  Argh.  I had a quick
> hack at it by trying to call CoCreateInstance again in make_link_2 if the 'sl'
> pointer wasn't already set but it still failed (same error); maybe w2k just
> isn't happy with having CoInit called so early.  I'm going to leave it for now
> because I want to get on with the libstdcxx support respin, but I could do
> some testing if you can think up a patch.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Dave Korn | 1 Jul 2009 13:58

Re: setup.exe CoCreateInstance error.

Corinna Vinschen wrote:

> Can you add debug code which checks the return code of the
> CoInitializeEx call in main.cc line 164?  Maybe that's already going
> wrong.

  Unfortunately no.  Happy return code zero.  I'm a security dork, so I
wondered if maybe something I've disabled was breaking it, so I fired up the
(normally disabled) DTC service, verified that DCOM was enabled using
dcomcnfg, and took a browse around in the component services MSC to make sure
it looked like it was working, but still no joy.

>  However, I don't know what to do besides of calling the
> functions in different places depending on the OS.  That really doesn't
> make sense.  I wish Microsoft had implemented a simple C function to
> create shortcuts, rather than providing only this COM nonsense.
> 
> Oh well, given that W7 is not yet RTMed, maybe the problem still goes
> away and the patch can be reverted.

  Would be good if it happens.  You gonna file a report with them?  (For all
the good that does :-/)

    cheers,
      DaveK
Permalink | Reply | 1 comment |
headers
Corinna Vinschen | 1 Jul 2009 14:05
Favicon

Re: setup.exe CoCreateInstance error.

On Jul  1 12:58, Dave Korn wrote:
> Corinna Vinschen wrote:
> 
> > Can you add debug code which checks the return code of the
> > CoInitializeEx call in main.cc line 164?  Maybe that's already going
> > wrong.
> 
>   Unfortunately no.  Happy return code zero.  I'm a security dork, so I
> wondered if maybe something I've disabled was breaking it, so I fired up the
> (normally disabled) DTC service, verified that DCOM was enabled using
> dcomcnfg, and took a browse around in the component services MSC to make sure
> it looked like it was working, but still no joy.

Grr.  I'd be glad if I could reproduce it because it would be nice,
for once, to have a Windows problem which at least pretends to be
deterministic.

> >  However, I don't know what to do besides of calling the
> > functions in different places depending on the OS.  That really doesn't
> > make sense.  I wish Microsoft had implemented a simple C function to
> > create shortcuts, rather than providing only this COM nonsense.
> > 
> > Oh well, given that W7 is not yet RTMed, maybe the problem still goes
> > away and the patch can be reverted.
> 
>   Would be good if it happens.  You gonna file a report with them?  (For all
> the good that does :-/)

I tried, but failed.  I spent an hour or two to create a simple
testcase, but I didn't succeed.  Which is to say, whatever I tried,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Schulman | 1 Jul 2009 16:12
Picon

[1.7] [RFU] atool

Please upload atool 0.36.0-1, leave 0.35.0-1 as the previous version, and
remove 0.34.0-2.

Thanks, Andrew.

wget \
 http://home.comcast.net/~andrex2/cygwin/atool/atool-0.36.0-1.tar.bz2 \
 http://home.comcast.net/~andrex2/cygwin/atool/atool-0.36.0-1-src.tar.bz2
Permalink | Reply | 1 comment |

Gmane