Dimitrie O. Paun wrote:
If it helps, here's a quick-n-dirty sample of how to check a signature:
gpg -q --batch --verify winetest-20040323-2314.zip.sig >/tmp/gpg 2>&1 ||
(echo "Bad signature, gpg reported:"; awk '{print " ",$0}' /tmp/gpg)
The problem is that this needs to execute on the
On Wed, 24 Mar 2004, Paul Millar wrote:
> OK, I'll provide [file].cookie with [file]'s MD5Sum. But we will need to
> migrate to using the signatures: a simple md5sum doesn't pass muster.
They have different purposes. We use the md5sum just like you do, to
determine if the client needs to downlo
On Wed, 24 Mar 2004, Dimitrie O. Paun wrote:
> > This is redundant with the (detached) signatures. But, just
> > s/.cookie/.sig/ and it works the same.
>
> I understand, but please provide the .cookie. Let's try to
> minimize changes at this point, OK?
OK, I'll provide [file].cookie with [file]'
On March 23, 2004 3:21 pm, Paul Millar wrote:
> > -- store the MD5SUM key that you've computed into a sister file
> > with the name winetest-.zip.cookie. It's URL will be:
> > http://theserver/path/winetest-.zip.cookie
>
> This is redundant with the (detached) signatures. But, just
> s
On Mon, 22 Mar 2004, Jakob Eriksson wrote:
> Excellent! Nitpicking, but could we publish winetest-MMDD0400.exe,
> UPX-packed? :-)
> As small as zip and no unpacking needed.
Sorry, just noticed your reply.
I've no particular preference for .zip or .exe; we can go with whichever
is easiest.
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> If Alxandre wants to do this, sure let's do it, but personally I
> don't want to burden him with the borring task of corking the
> commits every day. It adds borring, repetitive work jsut for
> saving a few hours of latency which I don't think ar
On Tue, 23 Mar 2004, Dimitrie O. Paun wrote:
> > The rest is just a matter of agreeing what to put where and how to
> > register new binaries.
[Sorry, I was just meaning this was perhaps drifting OT for wine-devel]
> I thought Brian told you already how we're going to do this.
Yes I was told, bu
On Tue, 23 Mar 2004, Paul Millar wrote:
> Hi Dimi,
>
> I guess we have to agree to disagree on this one. I still think that
> synchronous message-passing in distributed systems is a recipe for
> disaster (asynchronous is the only way to go). So schedule me a "told you
> so" email a few months a
On Tue, 23 Mar 2004, Dimitrie O. Paun wrote:
> If Alxandre wants to do this, sure let's do it, but personally I
> don't want to burden him with the borring task of corking the
> commits every day. It adds borring, repetitive work jsut for
> saving a few hours of latency which I don't think are a
Hi Dimi,
I guess we have to agree to disagree on this one. I still think that
synchronous message-passing in distributed systems is a recipe for
disaster (asynchronous is the only way to go). So schedule me a "told you
so" email a few months after the winetest.exe goes live ;^)
OK, so what I'll
On Tue, 23 Mar 2004, Geoff Thorpe wrote:
> Is it not possible, somehow, for Alexandre to indicate when he has
> finished a run of commits?
If Alxandre wants to do this, sure let's do it, but personally I
don't want to burden him with the borring task of corking the
commits every day. It adds b
Excuse the late jumping in, but ...
On March 22, 2004 06:50 pm, Dimitrie O. Paun wrote:
> As for the issue of nighly build vs. randomly initiated build: we can
> argue till the cows come home. It seems that we have different points
> of view. If you want to have CVS-triggered builds for WRT, all t
Paul Millar wrote:
Hi Dimi,
On Mon, 22 Mar 2004, Dimitrie O. Paun wrote:
Anyone should be able to reproduce the output by extracting this date
(from the .zip filename, or from winetest.exe), "cvs up -D"-ing and
cross-compiling themselves.
There are several problems with a variable build
Dimitrie O. Paun wrote:
Now, when do we build? I don't think we should trigger the build based
upon CVS commits, we need it a bit more controlled for a variety of
reasons. Here is what I propose:
-- decide on a time at night when the tree is very unlikely to change
(say 4am).
-- every day,
On Mon, 22 Mar 2004, Paul Millar wrote:
> > Yes, I meant EST. Or, as you can see from your graph, 10am GMT is perfect.
>
> OK. Its also the most likely time by which Alexandre has committed all
> the patches for that night (although it doesn't guarantee it). If we had
> to have a fixed build ti
Hi Dimi,
On Mon, 22 Mar 2004, Dimitrie O. Paun wrote:
> On Mon, 22 Mar 2004, Paul Millar wrote:
> > Does this *really* matter [if] we miss some patches?
>
> Yes, it does matter, and it's rather important. The test cycle is
> non-trivial, as I've already noted. It will take many hours to
> distrib
On Monday 22 March 2004 12:58, Ferenc Wagner wrote:
> > So, should I just do a "make -k" from the base directory
> > and leave broken tests to fail? (I haven't tried with the
> > current code, so this may be redundant now.)
Which tests are broken? I'm able to build all tests with
MinGW. MinGW do
On Monday 22 March 2004 11:25, Paul Millar wrote:
> I've also removed the urlmon test from programs/winetest/Makefile.in:
> TESTS variable, just to allow winetest.exe to build. Do you know if
> that's been fixed?
I've created a patch to add an urlmon import lib to the w32api
package of MinGW. It
Paul Millar <[EMAIL PROTECTED]> writes:
> On Mon, 22 Mar 2004, Ferenc Wagner wrote:
>
>> Paul Millar <[EMAIL PROTECTED]> writes:
>>
>>> For some reason, running make inside dlls directory
>>> generated more *_test.exe's than a simple "make -k".
>>
>> I guess this may be caused by the lib*.a impor
On Mon, 22 Mar 2004, Paul Millar wrote:
> Does this *really* matter? If we miss some patches, then WRT will just
> rebuild when it finishes the current cycle. The resulting binaries would
> be published once it done.
Yes, it does matter, and it's rather important. The test cycle is non-trivial,
Hi Ferenc,
On Mon, 22 Mar 2004, Ferenc Wagner wrote:
> Paul Millar <[EMAIL PROTECTED]> writes:
> > For some reason, running make inside dlls directory
> > generated more *_test.exe's than a simple "make -k".
>
> I guess this may be caused by the lib*.a import libs in
> dlls: using those of Wine i
Hi Dimi,
On Mon, 22 Mar 2004, Dimitrie O. Paun wrote:
> > Anyone should be able to reproduce the output by extracting this date
> > (from the .zip filename, or from winetest.exe), "cvs up -D"-ing and
> > cross-compiling themselves.
>
> There are several problems with a variable build time, but th
Paul Millar <[EMAIL PROTECTED]> writes:
> Currently the cross-build does something like:
>make -k; cd dlls; make -k; cd wine-mingw/programs/winetest; make
> but with an old-ish copy of wine CVS.
>
> For some reason, running make inside dlls directory
> generated more *_test.exe's than a simple
On Mon, 22 Mar 2004, Ferenc Wagner wrote:
> > Can I set WINE_BUILD to some fixed value? If so, what's a
> > good one to use?
>
> You can set it to anything that unambiguously identifies
> your build. Something like the date of the latest CVS
> commit.
'k. I'll use the date-stamp from the last
On Mon, 22 Mar 2004, Paul Millar wrote:
> 'k. AFAIK, that won't work like that (because of the COFF/PE internal
> checksum field) but it that's easily worked around: just build twice.
> The second time use the "real" WINE_BUILD date. Shouldn't hurt much.
Right. Moreover, the "fixed" build we
Hi Dimi,
On Mon, 22 Mar 2004, Dimitrie O. Paun wrote:
> > Can I set WINE_BUILD to some fixed value? If so, what's a good one to
> > use?
>
> The WINE_BUILD value must be valid, we can't distribute a winetest.exe
> with a fixed value in there. What you can do is fix it at build time
> to a known
Paul Millar <[EMAIL PROTECTED]> writes:
> On Sun, 21 Mar 2004, Jakob Eriksson wrote:
>
>> Ivan Leo Murray-Smith wrote:
>>
I am kind of holding my breath for a regular build of
winetest.exe - any chance for that soon? :-)
>>>
>>> It depends on how you define regular. If you mean
>>>
On Mon, 22 Mar 2004, Paul Millar wrote:
> From what I can see, the script programs/winetest/maketest builds the
> winetest.rc file. If the variable WINE_BUILD is set, it is used as the
> first element of the string-table, otherwise an auto-generated string is
> used, for example "20040322.1508-au
On Sun, 21 Mar 2004, Jakob Eriksson wrote:
> Ivan Leo Murray-Smith wrote:
> >>I am kind of holding my breath for a regular build of winetest.exe -
> >>any chance for that soon? :-)
> >>
> >It depends on how you define regular. If you mean daily/weekly builds,
> >I have no idea. But I can build
Ivan Leo Murray-Smith wrote:
I am kind of holding my breath for a regular build of winetest.exe - any
chance for that soon? :-)
It depends on how you define regular. If you mean daily/weekly builds, I have no
idea. But I can build winetest.exe when I build the win32 packages, when A.J.
rel
> I am kind of holding my breath for a regular build of winetest.exe - any
> chance for that soon? :-)
It depends on how you define regular. If you mean daily/weekly builds, I have no
idea. But I can build winetest.exe when I build the win32 packages, when A.J.
releases wine.
Ivan.
Ivan Leo Murray-Smith wrote:
So what we want is
wine-hdrs-.zip (headers)
wine-dlls-[-mingw].zip (2 packages with stripped and unstripped dlls)
wine-prgs-[-mingw].zip (2 packages with stripped and unstripped progs)
wine-w32api-[-mingw].zip (2 packages with stripped and unstripped libs)
right?
I
On March 20, 2004 8:01 am, Ivan Leo Murray-Smith wrote:
> So what we want is
> wine-hdrs-.zip (headers)
> wine-dlls-[-mingw].zip (2 packages with stripped and unstripped dlls)
> wine-prgs-[-mingw].zip (2 packages with stripped and unstripped progs)
> wine-w32api-[-mingw].zip (2 packages with stri
> Bug in binutils. A fix by Dimitry is in latest binutils.
OK, I'm rebuilding mingw with gcc-3.2.3-20030504-1,
binutils-2.15.90-20040222-1-src, mingw-runtime-3.2 and w32api-2.5, it should all
be up to date.
> MinGW folks split up the headers as well, (in their w32api package),
> and I think they a
--- Hans Leidekker <[EMAIL PROTECTED]> wrote:
> Some networking related dlls rely heavily on Unix networking APIs. It
>
> will probably take a while before they are rewritten to build on
> MinGW (with help from ReactOS perhaps?).
I tried to fix wininet but the WINE winsock headers are kind of
On Fri, 19 Mar 2004, Hans Leidekker wrote:
> > That's a good idea. In fact, maybe 3 packages: programs, dlls, headers:
> > wine-prgs-[-mingw].zip
> > wine-dlls-[-mingw].zip
> > wine-hdrs-.zip
> >
> > MinGW folks split up the headers as well, (in their w32api package),
> > and I think
On Friday 19 March 2004 14:21, Dimitrie O. Paun wrote:
> That's a good idea. In fact, maybe 3 packages: programs, dlls, headers:
> wine-prgs-[-mingw].zip
> wine-dlls-[-mingw].zip
> wine-hdrs-.zip
>
> MinGW folks split up the headers as well, (in their w32api package),
> and I th
On March 19, 2004 7:54 am, Hans Leidekker wrote:
> I think it would be nice if we provided just two packages: one
> with PE versions of our programs. Just the relevant ones that
> actually build, so no winecfg or winedbg for example, and a
> second package with PE dlls that build.
That's a good id
On Wednesday 17 March 2004 18:05, Ivan Leo Murray-Smith wrote:
> > Can you please post the list of errors to wine-devel, so people are aware of the
> > problems (and hopefully send patches to fix them :))?
> Complete compile error log is attached.
../../../wine-src/tools/winebuild/spec32.c: In
> Can you please post the list of errors to wine-devel, so people are aware of the
> problems (and hopefully send patches to fix them :))?
Complete compile error log is attached.
> Now that we have this build, can we get rid of:
> Wine programs for Windows
> from the "Support Files" package?
On Wed, 17 Mar 2004, Ivan Leo Murray-Smith wrote:
> The win32 packages of wine are on sourceforge, you can get them from
> http://sourceforge.net/project/showfiles.php?group_id=6241
> or to view the win32 packages only
> http://sourceforge.net/project/showfiles.php?group_id=6241&package_id=112520
The win32 packages of wine are on sourceforge, you can get them from
http://sourceforge.net/project/showfiles.php?group_id=6241
or to view the win32 packages only
http://sourceforge.net/project/showfiles.php?group_id=6241&package_id=112520
Ivan.
42 matches
Mail list logo
