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:
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.
That would be a LOT better than what we have now.
regards, Jakob
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 winetest.exe when I build the win32 packages, when A.J. releases wine.
That would be a LOT better than what we have now.
I'm adding cross-building as part of WRT, so we'd get winetest.exe rebuilt as changes are made to CVS (& everything else too, if people want that). Its nearly there, having worked around some mingw/COFF nasties. There's one last hurdle: winetest.exe itself.
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-auto".
This makes winetest.exe build-time-dependant, so screws up the check to see if anything's actually changed.
Can I set WINE_BUILD to some fixed value? If so, what's a good one to use?
Cheers,
Paul.
---- Paul Millar
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-auto".
This makes winetest.exe build-time-dependant, so screws up the check to see if anything's actually changed.
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 value (say YYYYMMDDhhmm), and replace it after the build with the proper value.
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, at 4:10am we do: cvs up -D YYYYMMDD0400 (this way we know _precicely_ what we built, and we can reporduce it) -- do the build (fix WINE_BUILD), check if the winetest.exe really changed. -- if it changed, edit WINE_BUILD and set it to YYYYMMDD0400. -- publish the result as winetest-YYYYMMDD0400.zip via the CGI script
But the main point here is that we can't build based on CVS committs, we need a well known, controlled point where we build so that developers can reproduce the build and investigate problems.
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 value (say YYYYMMDDhhmm), and replace it after the build with the proper value.
'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.
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.
... err, why? This is how WRT works. The idea was to tag the cross-building as part of what WRT does normally, so its easiest to cross-build on-demand rather than via a cron job.
Here is what I propose: -- decide on a time at night when the tree is very unlikely to change (say 4am). -- every day, at 4:10am we do: cvs up -D YYYYMMDD0400 (this way we know _precicely_ what we built, and we can reporduce it) -- do the build (fix WINE_BUILD), check if the winetest.exe really changed. -- if it changed, edit WINE_BUILD and set it to YYYYMMDD0400. -- publish the result as winetest-YYYYMMDD0400.zip via the CGI script
OK, that would work, but I don't see the need for this. Plus, building at fixed times makes it less flexible. Suppose Alexandre is working late, or from somewhere foreign :)
But the main point here is that we can't build based on CVS committs, we need a well known, controlled point where we build so that developers can reproduce the build and investigate problems.
The two points are orthogonal, well-known control points are achieved by storing when the CVS update was done in the .zip filename and in the WINE_BUILD string (stored within the winetest.exe).
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.
Cheers,
Paul.
---- Paul Millar
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 should do without the revision information (see Feri's email, he points you to one of my emails describing it :)), while the real build should include the proper WINE_BUILD tag, and the revision info.
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 the biggest one is that one can not tell when Alexandre finished the commits for the day just by looking at wine-cvs messages. If you look back 5 years, you will not see a single instance of commits at say 4am, yet there will be plenty of examples where any (not overly complicated) algorithm will fail to detect the end of the commits for the day.
The build is time consuming, and it will take the better part of the day to do a proper: build, distribute, test, gather results cycle. We gain almost nothing with a CVS-based trigger, other than unwanted variability. Having a well defined nightly build just simplifies everybody's life, it's simple to document, and understand. Please lets not complicate things just because we can.
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 the biggest one is that one can not tell when Alexandre finished the commits for the day just by looking at wine-cvs messages.
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.
If you look back 5 years, you will not see a single instance of commits at say 4am, yet there will be plenty of examples where any (not overly complicated) algorithm will fail to detect the end of the commits for the day.
Errr, 'fraid I don't see the 4am part (unless you mean at precisely 04:00:00). Taking data from the past year from: http://www.winehq.org/hypermail/wine-cvs/ Downloading the "downloadable version", and running a wee 1-oner: grep -h Date: 200[34].*|cut -d: -f2-|while read d; do date -d "$d" +%k >> output; done; sort -n output | uniq -c | awk '{print $2,$1}' > commit.dat Gnuplot it with: plot [-0.5:23.5] "commit.dat" not w boxes The results are: http://www.astro.gla.ac.uk/users/paulm/cvs_commit.png There's actually a peak of commits at 4am.
This is of course all UK local time. Do you mean 4am in one of the US-time-zones? (=> ~ 9am-11am or so?).
Hmmm, in the past year there've been patches a 7am, 8am, 11am and 13am. There haven't been any 9am and 10am, but looking at the data it wouldn't be impossible for Alexandre to commit at usual hours of the day or night :)
The build is time consuming, and it will take the better part of the day to do a proper: build, distribute, test, gather results cycle.
Actually, the build time isn't *that* time consuming. Running ccache and distcc, it currently takes about an hour to build both native and cross-compilation. With a bit of effort, I'm sure that could be improved a fair bit. As soon as the cross-compilation is finished, the binaries are available to be published.
The time-consuming bit at the moment is running the tests within wine, which is bad because of the way that's done within WRT. That needs fixing, but it's largely independent of the cross-building, publishing steps.
We gain almost nothing with a CVS-based trigger, other than unwanted variability. Having a well defined nightly build just simplifies everybody's life, it's simple to document, and understand. Please lets not complicate things just because we can.
Well, the CVS-based trigger is already implemented, debugged, tested and works. Making it trigger at a fixed time would be fairly easy to do, but involves changing something that's working. But making the time fixed isn't necessary, and just give us a potential point-of-failure.
---- Paul Millar
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, as I've already noted. It will take many hours to distribute and run the tests. The clients can (and most likely) will schedule their local daemons to run only during certain timeframes (when they don't use their boxes). This means that we can expect a full test cycle to take close to 24h. I don't want to have some clients go off and test on a spurious build. We have _one_ shot per day for a build, and it better be the right one.
The results are: http://www.astro.gla.ac.uk/users/paulm/cvs_commit.png There's actually a peak of commits at 4am.
This is of course all UK local time. Do you mean 4am in one of the US-time-zones? (=> ~ 9am-11am or so?).
Yes, I meant EST. Or, as you can see from your graph, 10am GMT is perfect.
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 distribute and run the tests.
I'm afraid I still don't see why it should take hours. The binaries should be available for the client to download a minute or so after the compilation finishes. The clients can run the code whenever their users decide: we have no control over that. We should just collect the results and put them into the DB, along with which patches have been applied (like tinderbox).
The clients can (and most likely) will schedule their local daemons to run only during certain timeframes (when they don't use their boxes). This means that we can expect a full test cycle to take close to 24h.
Yes, one possibility is for client code to be configured to poll for a certain period, say 9pm to 6am (assuming the PC is left on overnight). The 11pm poll could pick up an early build and the 3am one could pick up a later one.
But ultimately its the end-user's choice when the winetest.exe code should be downloaded and run; we can't mandate this. The best we can do is try and utilise that time as effectively as possible, which means building and distributing winetest.exe as quickly as possible.
Dictating a specific build-time limits us to a single cycle per day. If people were willing to allow the client to poll over night, we couldn't make use of that. It also forces everyone to test at about the same time. 4am is OK for people in American, but its terrible for Europeans.
I don't want to have some clients go off and test on a spurious build. We have _one_ shot per day for a build, and it better be the right one.
Ah! Perhaps this is the misunderstanding: they're not "spurious" builds, they're builds with less patches applied.
If there's a problem, then a build with less patches is valuable. If it passes, then it tells us which patches are not the causing the problem, if not then there's less patches to search through for the problem.
Either way, it narrows down the problem without developer's having to think about it. Developer's time is precious and should be spend doing "difficult" problems, not doing trivial things like tracking down which patch caused the problem. :)
The results are: http://www.astro.gla.ac.uk/users/paulm/cvs_commit.png There's actually a peak of commits at 4am.
This is of course all UK local time. Do you mean 4am in one of the US-time-zones? (=> ~ 9am-11am or so?).
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 time, its the best time; but I wouldn't describe it as perfect (but maybe that's just me being awkward :^)
---- Paul Millar
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 time, its the best time; but I wouldn't describe it as perfect (but maybe that's just me being awkward :^)
Whatever you want to call it, but yes, 10am GMT is the most natural end/begin of the 24h cycle. It seems to be a rather good choice.
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 the power to you, they makes sense in that (controlled) environment. For the nightly builds however, I would really like having a build that's kicked off at a precise moment in time (and as we discussed, 10GMT seems a good choice).
Please try to understand that as a developer on Wine, having this extra variability adds _nothing_ but headache. It makes it harder to think about the problem, to talk about it, to script for it, etc. I don't need it, and I don't want it.
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 the power to you, they makes sense in that (controlled) environment. For the nightly builds however, I would really like having a build that's kicked off at a precise moment in time (and as we discussed, 10GMT seems a good choice).
Is it not possible, somehow, for Alexandre to indicate when he has finished a run of commits? I know he endeavours to keep CVS stable by committing under the "Do No Harm" principle, but obviously the chances of hitting a snag are greater during a run of commits than once they are done. Certainly the *usefulness* of the testing is greater once the run is over, no matter what time(s) of day he may choose to do such processing. Presumably Alexandre has some mechanism of his own to incrementally test things during the wine-patches --> wine-cvs processing. Presumably also, there is some point in that mechanism of his where he might like having a large green button to the effect of; "thou alt solid locally, release thyself unto the distributed test network whereapon I shall know thy fidelity on the morrow". Or words to the effect ...
Please try to understand that as a developer on Wine, having this extra variability adds _nothing_ but headache. It makes it harder to think about the problem, to talk about it, to script for it, etc. I don't need it, and I don't want it.
Exactly, and again Alexandre is not only another (the?) wine developer, but also the one pulling the CVS strings - surely there must be some painless way to trigger these "snapshot moments" from his end. That is, after timezones have been argued to hell and back, really the only place where the right moment for a useful test can be accurately determined (and without unduly delay).
Cheers, Geoff
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 borring, repetitive work jsut for saving a few hours of latency which I don't think are a problem.
But that's just me. If he's happy to do so, by all means!
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 problem.
Yes, and there's always the possibility of error: Alexandre is only human (... least I think so). As Dimi says, boring and repetative, surely what computers are here to prevent.
---- Paul Millar
"Dimitrie O. Paun" dimi@intelliware.ca 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 are a problem.
But that's just me. If he's happy to do so, by all means!
Well, I don't mind running a script when commits are done, but I'm bound to forget it from time to time, so an automated mechanism is probably a better choice.
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 do is finalise things here and set up a cron job (at 10am localtime) to build winetest.exe and publish the results somewhere. That should be fairly simple. The rest is just a matter of agreeing what to put where and how to register new binaries. The on-demand builds will continue (as they might as well) and kept somewhere separate.
I'm GPG-signing all the binaries, as this is trivial for me to do and should help improve security a bit. The auto-signing key doesn't have a pass-phrase (so its only as good as the integrity of the machine), but that's true for auto-built binaries anyway. I'll sign the auto-signing key with my own key (available from my web site) and publicly announce it soon.
I'm no GPG expert, but does that sound OK?
Paul.
PS Just as an aside, when do people in the US change their clocks? Everyone in the EU is changing to DLS-time (BST in the UK) this Sunday.
On Mon, 22 Mar 2004, Dimitrie O. Paun wrote:
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 time, its the best time; but I wouldn't describe it as perfect (but maybe that's just me being awkward :^)
Whatever you want to call it, but yes, 10am GMT is the most natural end/begin of the 24h cycle. It seems to be a rather good choice.
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 the power to you, they makes sense in that (controlled) environment. For the nightly builds however, I would really like having a build that's kicked off at a precise moment in time (and as we discussed, 10GMT seems a good choice).
Please try to understand that as a developer on Wine, having this extra variability adds _nothing_ but headache. It makes it harder to think about the problem, to talk about it, to script for it, etc. I don't need it, and I don't want it.
---- Paul Millar
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 after the winetest.exe goes live ;^)
Noted. :)
OK, so what I'll do is finalise things here and set up a cron job (at 10am localtime) to build winetest.exe and publish the results somewhere. That should be fairly simple.
Thank you, thank you, thank you!
The rest is just a matter of agreeing what to put where and how to register new binaries.
I thought Brian told you already how we're going to do this. Here are the steps again: -- you build a new winetest.exe -- zip it into a file named winetest-<YYYYMMDDhhmm>.zip, where <YYYYMMDDhhmm> is our BUILD_ID we've discussed about in the past -- store this file on the server, and say that the URL to it will be: http://theserver/path/winetest-<YYYYMMDDhhmm>.zip -- store the MD5SUM key that you've computed into a sister file with the name winetest-<YYYYMMDDhhmm>.zip.cookie. It's URL will be: http://theserver/path/winetest-<YYYYMMDDhhmm>.zip.cookie -- send the following request (using lynx): http://test.winehq.org/service?publish=winetest&url=http://theserver/pat...<YYYYMMDDhhmm>.zip -- expect an 'OK' back as a response
Still to be decided: A. The winetest.exe that we'll store in the .zip we'll keep under this name, or we'll rename it to winetest-<YYYYMMDDhhmm>.exe? IIRC my chat with Chris, we should keep it as winetest.exe B. I guess that the GPG signature will do into the .zip file as an ASCII file. How do we name that? I would prefer something like 'winetest-<YYYYMMDDhhmm>.asc' or somesuch. C. You need to tell us _exactly_ what the 'http://theserver/path/' is going to be. We need to store that on the WineHQ end to protect against others doing nasty stuff with our distribution system. :)
I'm GPG-signing all the binaries, as this is trivial for me to do and should help improve security a bit. The auto-signing key doesn't have a pass-phrase (so its only as good as the integrity of the machine), but that's true for auto-built binaries anyway. I'll sign the auto-signing key with my own key (available from my web site) and publicly announce it soon.
I'm no GPG expert, but does that sound OK?
Sounds good. Having it signed is a good idea, and you can go ahead and implement it. It may take us a bit longer to actually check the signature, but that's a different matter.
Just as an aside, when do people in the US change their clocks? Everyone in the EU is changing to DLS-time (BST in the UK) this Sunday.
Does it matter? Is UTC dependant on the daylight savings time?
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, but it could be made more secure without that much effort now that the .zip files are being signed ... but its detail that could be hammered out without wasting wine-devel bandwidth.
[...snip...]
-- store the MD5SUM key that you've computed into a sister file with the name winetest-<YYYYMMDDhhmm>.zip.cookie. It's URL will be: http://theserver/path/winetest-<YYYYMMDDhhmm>.zip.cookie
This is redundant with the (detached) signatures. But, just s/.cookie/.sig/ and it works the same.
BTW, we can't just store the md5sums on the web page as DNS poisoning would subvert the security. Using signed binaries means we're secure (I think ;) except for replay attacks and someone breaking into quisquiliae. The former is ameliorated by checking that the .ZIP file's creation date is reasonable, but the latter is an inherent risk.
Still to be decided:
[...snip...]
B. I guess that the GPG signature will do into the .zip file as an ASCII file. How do we name that? I would prefer something like 'winetest-<YYYYMMDDhhmm>.asc' or somesuch.
I'm currently signing the whole .zip file as a detached signature. Like with the md5sum .cookie idea, but called .sig. Anyone should be able to verify it with: gpg --verify winetest-<date>.zip.sig (with winetest-<date>.zip in cwd).
If it passes, you know (with some certainty) that it came from the auto-build machine.
C. You need to tell us _exactly_ what the 'http://theserver/path/' is going to be. We need to store that on the WineHQ end to protect against others doing nasty stuff with our distribution system. :)
By all means, but its redundant if the .ZIP file is signed.
[using signed binaries]
Sounds good. Having it signed is a good idea, and you can go ahead and implement it. It may take us a bit longer to actually check the signature, but that's a different matter.
Hmmm, probably about the same speed. AFAIK, gpg using md5sums internally (within signatures), so its the time taken to decrypt a md5sum in the signature, calculate the md5sum of the .ZIP file and compare the two.
Just as an aside, when do people in the US change their clocks? Everyone in the EU is changing to DLS-time (BST in the UK) this Sunday.
Does it matter? Is UTC dependant on the daylight savings time?
AFAIK, cron uses local time. If US jumps at a different time, there may be additional headaches :^/
---- Paul Millar
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-<YYYYMMDDhhmm>.zip.cookie. It's URL will be: http://theserver/path/winetest-<YYYYMMDDhhmm>.zip.cookie
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?
C. You need to tell us _exactly_ what the 'http://theserver/path/' is going to be. We need to store that on the WineHQ end to protect against others doing nasty stuff with our distribution system. :)
By all means, but its redundant if the .ZIP file is signed.
Again, I understand, but let's keep this as well.
Sounds good. Having it signed is a good idea, and you can go ahead and implement it. It may take us a bit longer to actually check the signature, but that's a different matter.
Hmmm, probably about the same speed. AFAIK, gpg using md5sums internally (within signatures), so its the time taken to decrypt a md5sum in the signature, calculate the md5sum of the .ZIP file and compare the two.
I was talking about implmentation speed :) That is, it may take us a bit longer to actually check the sig, but we can go ahead without it.
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]'s MD5Sum. But we will need to migrate to using the signatures: a simple md5sum doesn't pass muster.
[...]
I was talking about implmentation speed :) That is, it may take us a bit longer to actually check the sig, but we can go ahead without it.
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)
HTH
---- Paul Millar
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 download the new winetest.
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 client box, so we need the gpg installed there. I don't know how this is going to work out. It's up to Chris, but we can skip this sig validation for now.
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 client box, so we need the gpg installed there. I don't know how this is going to work out. It's up to Chris, but we can skip this sig validation for now.
AFAIK we could install gpg.exe at the same place as the test service with the NullSoft installer script. (GPG works the same on Windows as on Linux, just tested it.)
regards, Jakob
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 time, but the biggest one is that one can not tell when Alexandre finished the commits for the day just by looking at wine-cvs messages.
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.
I suspect this discussion is a bit over my head, but isn't the issue this: with CVS triggered we can have several winetest.exe released the same day.
Is this desirable or not? Would it break Ferencs CGI and database?
regards, Jakob
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, at 4:10am we do: cvs up -D YYYYMMDD0400 (this way we know _precicely_ what we built, and we can reporduce it) -- do the build (fix WINE_BUILD), check if the winetest.exe really changed. -- if it changed, edit WINE_BUILD and set it to YYYYMMDD0400. -- publish the result as winetest-YYYYMMDD0400.zip via the CGI script
Excellent! Nitpicking, but could we publish winetest-YYYYMMDD0400.exe, UPX-packed? :-) As small as zip and no unpacking needed.
But the main point here is that we can't build based on CVS committs, we need a well known, controlled point where we build so that developers can reproduce the build and investigate problems.
Agreed. Good you spent some thought on this.
regards, Jakob
On Mon, 22 Mar 2004, Jakob Eriksson wrote:
Excellent! Nitpicking, but could we publish winetest-YYYYMMDD0400.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. Although I think some people prefer ZIP-files as the tools for dealing with them are more wide-spread.
What would people prefer?
---- Paul Millar
Paul Millar paulm@astro.gla.ac.uk 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 daily/weekly builds, I have no idea. But I can build winetest.exe when I build the win32 packages, when A.J. releases wine.
That would be a LOT better than what we have now.
I'm adding cross-building as part of WRT, so we'd get winetest.exe rebuilt as changes are made to CVS (& everything else too, if people want that). Its nearly there, having worked around some mingw/COFF nasties. There's one last hurdle: winetest.exe itself.
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-auto".
This makes winetest.exe build-time-dependant, so screws up the check to see if anything's actually changed.
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.
Two side notes: * winetest.exe (cross-compiled) is unusable at the moment, working on it * please read the comment in Dimi's recent patch: http://www.winehq.org/hypermail/wine-patches/2004/03/0258.html
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 CVS update. I just need to set this...
Two side notes:
- winetest.exe (cross-compiled) is unusable at the moment, working on it
Great. 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 "make -k". I guess that might be fixed now, there've been a fair number of cross-comp. patches recently.
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?
- please read the comment in Dimi's recent patch: http://www.winehq.org/hypermail/wine-patches/2004/03/0258.html
Yup. I'll play with that next, once the publishing is working.
Cheers,
Paul.
---- Paul Millar
Paul Millar paulm@astro.gla.ac.uk 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 "make -k".
I guess this may be caused by the lib*.a import libs in dlls: using those of Wine is not the same as using the MinGW versions.
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?
Probably not. Quite some time ago I downloaded liburlmon.a from the net, from a MinGW development directory, if my memory serves me right. That lets me link the urlmon test. http://afavant.elte.hu/~wferi/wine/liburlmon.a if interested.
Hi Ferenc,
On Mon, 22 Mar 2004, Ferenc Wagner wrote:
Paul Millar paulm@astro.gla.ac.uk 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 is not the same as using the MinGW versions.
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.)
I've also removed the urlmon test [...] just to allow winetest.exe to build. Do you know if that's been fixed?
Probably not.
So, should we remove (from Makefile.in) tests that currently block winetest.exe from building? To me, building /something/ is better than nothing. Extra tests can be added once they're building correctly.
Quite some time ago I downloaded liburlmon.a from the net, from a MinGW development directory, if my memory serves me right. That lets me link the urlmon test. http://afavant.elte.hu/~wferi/wine/liburlmon.a if interested.
Thanks, I'll have a look.
---- Paul Millar
Paul Millar paulm@astro.gla.ac.uk writes:
On Mon, 22 Mar 2004, Ferenc Wagner wrote:
Paul Millar paulm@astro.gla.ac.uk 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 is not the same as using the MinGW versions.
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.)
I don't know, really. I'm not sure what these import libraries really are, just guessing. Can anybody help out?
I've also removed the urlmon test [...] just to allow winetest.exe to build. Do you know if that's been fixed?
Probably not.
So, should we remove (from Makefile.in) tests that currently block winetest.exe from building? To me, building /something/ is better than nothing. Extra tests can be added once they're building correctly.
Yes, it's probably better than making the make process more forgiving. Requires maintenance, though.
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 does still need an urlmon import lib (see my other post) and some DirectX guids but other than that I've fixed all test to build on MinGW (last to path iphlpapi test is not committed yet though).
-Hans
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's in my MinGW cross compiler RPM packages and you can find the patch attached.
-Hans
-
Alexandre Julliard -
Dimitrie O. Paun -
Dimitrie O. Paun -
Ferenc Wagner -
Geoff Thorpe -
Hans Leidekker -
Ivan Leo Murray-Smith -
Jakob Eriksson -
Paul Millar