Thread: [Audacity-devel] 1.3.13rc3 freeze
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Vaughan J. <va...@au...> - 2011-04-06 19:12:43
|
Haven't heard from Martyn yet about what's the best UTC time for freezes, such that rc's can be built without forcing some builders to stay up too late. I believe it's now just after 8pm in London, 7pm UTC. I think that's probably a reasonable time, and just after noon here in California. If we set it for 19:00 UTC, we'll have a few hours before Leland gets home from work, but I think that's okay, relative to not making it too late for east of the Atlantic. I haven't seen any other P1's or P2's noted. So I'm calling the freeze for right now. Please build and post the rc3's. Thanks, Vaughan |
From: Leland L. <lll...@gm...> - 2011-04-06 20:11:31
|
On Wed, Apr 6, 2011 at 2:14 PM, Vaughan Johnson <va...@au...> wrote: > Haven't heard from Martyn yet about what's the best UTC time for > freezes, such that rc's can be built without forcing some builders to > stay up too late. > > I believe it's now just after 8pm in London, 7pm UTC. I think that's > probably a reasonable time, and just after noon here in California. If > we set it for 19:00 UTC, we'll have a few hours before Leland gets home > from work, but I think that's okay, relative to not making it too late > for east of the Atlantic. > Freeze away. I'll build around 8pm Central. But, unlike Martyn, I don't mind saying up to 3 or 4 in the morning. :-D (just kidding Martyn...I often say up that late anyway.) Leland |
From: Leland <le...@au...> - 2011-04-06 20:12:12
|
On Wed, Apr 6, 2011 at 2:14 PM, Vaughan Johnson <va...@au...> wrote: > Haven't heard from Martyn yet about what's the best UTC time for > freezes, such that rc's can be built without forcing some builders to > stay up too late. > > I believe it's now just after 8pm in London, 7pm UTC. I think that's > probably a reasonable time, and just after noon here in California. If > we set it for 19:00 UTC, we'll have a few hours before Leland gets home > from work, but I think that's okay, relative to not making it too late > for east of the Atlantic. > > I haven't seen any other P1's or P2's noted. > > So I'm calling the freeze for right now. Please build and post the rc3's. > Freeze away. I'll build around 8pm Central. But, unlike Martyn, I don't mind saying up to 3 or 4 in the morning. :-D (just kidding Martyn...I often say up that late anyway.) Leland |
From: Leland <le...@au...> - 2011-04-07 00:48:35
|
On 4/6/11 2:14 PM, Vaughan Johnson wrote: > So I'm calling the freeze for right now. Please build and post the rc3's. > Mac and tarballs built and uploaded. Leland |
From: Vaughan J. <va...@au...> - 2011-04-07 02:21:31
|
All the rc3's except ANSI are posted. Please begin testing. Next freeze is 19:00 UTC on April 5. Thanks, Vaughan |
From: Gale (A. Team) <ga...@au...> - 2011-04-07 04:25:38
|
Vaughan wrote: > All the rc3's except ANSI are posted. Please begin testing. ANSI were posted a while ago: http://audacity.googlecode.com/files/audacity-win-1.3.13rc3.zip http://audacity.googlecode.com/files/audacity-win-1.3.13rc3.exe > Next freeze is 19:00 UTC on April 5. You mean April 8, I presume? The Google Code downloads page is a mess with rc1's, 2's and 3's. Shall I remove the old ones as usual, and note to do this on http://wiki.audacityteam.org/wiki/Release_Process#Release_Candidates? Ed was asking if the Manual should freeze while the code freeze was in place, and I suggested "no" because the Manual would have to change if a P1/P2 fix demanded it, and because at the moment the Manual hasn't quite kept up with the code changes anyway. In future we're aiming to keep the online Manual up-to-date with the current Nightly Builds if everyone is agreeable to that, so that there aren't mistakes and omissions in the last minute rush. However Ed has a point in that if we don't freeze the Manual, then Win/Mac packagers could pull slightly different versions of the Manual. We have that issue now in that the Extended Import Preferences are incomplete in Martyn's builds and a bit less incomplete in mine, and could be different again in Leland's. I have now finished that page off as best I can, so at least it's correct online. So what I was thinking was maybe packagers shouldn't build the help project (I guess normally they don't anyway) and Release Manager should delegate someone to pull the Manual and post it, so that everyone used that version. Of course for stable we might want to have the Manual finished and approved for rc1 anyway, barring P1/P2 fixes. I noticed Martyn's 1.3.13rc3 again has the later msvc* dll's so I presume that's all he has. Did we decide what if anything to do about that? Gale -- View this message in context: http://audacity.238276.n2.nabble.com/1-3-13rc3-freeze-tp6247268p6248616.html Sent from the audacity-devel mailing list archive at Nabble.com. |
From: Vaughan J. <va...@au...> - 2011-04-07 22:17:57
|
On 4/6/2011 9:25 PM, Gale (Audacity Team) wrote: > Vaughan wrote: >> All the rc3's except ANSI are posted. Please begin testing. > > ANSI were posted a while ago: > http://audacity.googlecode.com/files/audacity-win-1.3.13rc3.zip > http://audacity.googlecode.com/files/audacity-win-1.3.13rc3.exe Please let RM and/or the lists know when you post them. > > >> Next freeze is 19:00 UTC on April 5. > > You mean April 8, I presume? Yes. Typo. Meant April 8. Although if I could specify it should be due a day before I wrote it should be due, I'd specify we get 2.0 out a year ago. :-) > > The Google Code downloads page is a mess with rc1's, 2's and 3's. Shall I > remove the old ones as usual, and note to do this on > http://wiki.audacityteam.org/wiki/Release_Process#Release_Candidates? I'd like to avoid lots of cross-editing on that page while I'm RM. And I have some exceptions to some of the changes that have been made since my major edit. Will get to those later. > > Ed was asking if the Manual should freeze while the code freeze was in > place, and I suggested "no" because the Manual would have to change if a > P1/P2 fix demanded it, and because at the moment the Manual hasn't quite > kept up with the code changes anyway. I think this is the fourth separate thread where I'm in a discussion about this. I already answered in an off-list thread among Manual Team. Will re-post that on these lists, where it really should happen. >In future we're aiming to keep the > online Manual up-to-date with the current Nightly Builds if everyone is > agreeable to that, so that there aren't mistakes and omissions in the last > minute rush. +1. > > However Ed has a point in that if we don't freeze the Manual, then Win/Mac > packagers could pull slightly different versions of the Manual. We have that > issue now in that the Extended Import Preferences are incomplete in Martyn's > builds and a bit less incomplete in mine, and could be different again in > Leland's. I did not know about that. Aren't you all building from the same code?!!! That's what "freeze" means! >I have now finished that page off as best I can, so at least it's > correct online. So what I was thinking was maybe packagers shouldn't build > the help project (I guess normally they don't anyway) and Release Manager > should delegate someone to pull the Manual and post it, so that everyone > used that version. Of course for stable we might want to have the Manual > finished and approved for rc1 anyway, barring P1/P2 fixes. I will update the Release Process page for that. > > I noticed Martyn's 1.3.13rc3 again has the later msvc* dll's so I presume > that's all he has. Did we decide what if anything to do about that? Thanks for checking. I thought that was resolved already. Martyn? - Vaughan |
From: Gale (A. Team) <ga...@au...> - 2011-04-07 23:21:26
|
Vaughan wrote: > > The Google Code downloads page is a mess with rc1's, 2's and 3's. Shall > I > > remove the old ones as usual, and note to do this on > > http://wiki.audacityteam.org/wiki/Release_Process#Release_Candidates? > I'd like to avoid lots of cross-editing on that page while I'm RM. And I > have some exceptions to some of the changes that have been made since my > major edit. Will get to those later. OK, but what policy would you like on only having the current rc up on Google Code? In past releases I just deleted the old ones straight away without anyone objecting. >> However Ed has a point in that if we don't freeze the Manual, then >> Win/Mac >> packagers could pull slightly different versions of the Manual. We have >> that >> issue now in that the Extended Import Preferences are incomplete in >> Martyn's >> builds and a bit less incomplete in mine, and could be different again in >> Leland's. > I did not know about that. Aren't you all building from the same > code?!!! That's what "freeze" means! Of course, we're all building from the same source code. But if the Manual is quite badly behind the code at start of rc1 which was true this time, and allowed to catch up during the code freeze, then slightly different versions of the Manual could be pulled according to when someone starts to build (without e.g. someone pulling the manual and saying this is the one we're building with). Another problem - bug 350 which Bill reported as PX a day or so ago: http://bugzilla.audacityteam.org/show_bug.cgi?id=350 This is a hard one to rate. If you have selected in the Device Toolbar then used the Play or Record shortcut, all other shortcuts are blocked. Most people would figure out to hit Stop sooner or later, but it's an embarrassment (IMO) and (I figure) a major problem for VI users as I can't see how they get out of it unless they can deliver a click somehow. So at the moment I have it as P2. That doesn't mean we have to fix it now, but it would be hard (IMO) not to release note it (which means P3) and then that requires rebuild anyway. PS Thanks for those tests, Leland. Gale -- View this message in context: http://audacity.238276.n2.nabble.com/1-3-13rc3-freeze-tp6247268p6251915.html Sent from the audacity-devel mailing list archive at Nabble.com. |
From: Vaughan J. <va...@au...> - 2011-04-08 01:38:31
|
On 4/7/2011 4:21 PM, Gale (Audacity Team) wrote: > Vaughan wrote: >>> The Google Code downloads page is a mess with rc1's, 2's and 3's. Shall >> I >>> remove the old ones as usual, and note to do this on >>> http://wiki.audacityteam.org/wiki/Release_Process#Release_Candidates? >> I'd like to avoid lots of cross-editing on that page while I'm RM. And I >> have some exceptions to some of the changes that have been made since my >> major edit. Will get to those later. > OK, but what policy would you like on only having the current rc up on > Google Code? In past releases I just deleted the old ones straight away > without anyone objecting. Yes, I'm fine with that and will document it. Please delete them. Thanks. > > >>> However Ed has a point in that if we don't freeze the Manual, then >>> Win/Mac >>> packagers could pull slightly different versions of the Manual. We have >>> that >>> issue now in that the Extended Import Preferences are incomplete in >>> Martyn's >>> builds and a bit less incomplete in mine, and could be different again in >>> Leland's. >> I did not know about that. Aren't you all building from the same >> code?!!! That's what "freeze" means! > Of course, we're all building from the same source code. But if the Manual > is quite badly behind the code at start of rc1 which was true this time, and > allowed to catch up during the code freeze, then slightly different versions > of the Manual could be pulled according to when someone starts to build > (without e.g. someone pulling the manual and saying this is the one we're > building with). That's exactly why I said the freeze schedules should be synchronized, and the manual frozen for each rc. Yes, if the manual changes during the rc freeze, nothing will break, but it's relative chaos unless it freezes again at the next 48-hour freeze deadline. I'm open to work on "P2" manual changes in that 48-hour cycle if they can be completed before the next rc freeze. > > Another problem - bug 350 which Bill reported as PX a day or so ago: > http://bugzilla.audacityteam.org/show_bug.cgi?id=350 > > This is a hard one to rate. If you have selected in the Device Toolbar then > used the Play or Record shortcut, all other shortcuts are blocked. Most > people would figure out to hit Stop sooner or later, but it's an > embarrassment (IMO) and (I figure) a major problem for VI users as I can't > see how they get out of it unless they can deliver a click somehow. So at > the moment I have it as P2. That doesn't mean we have to fix it now, but it > would be hard (IMO) not to release note it (which means P3) and then that > requires rebuild anyway. I think it's a P3. But shouldn't the "release note it" rule be for P3 or higher? Why would a release note change require rebuild? I thought that problem with README changes needing rebuild was solved already by posting to web. - Vaughan |
From: Gale (A. Team) <ga...@au...> - 2011-04-09 04:20:38
|
Vaughan wrote: >>On 4/7/2011 4:21 PM, Gale (Audacity Team) wrote: >> but what policy would you like on only having the current rc up on >> Google Code? In past releases I just deleted the old ones straight away >> without anyone objecting. > Yes, I'm fine with that and will document it. Please delete them. Thanks. OK we only have rc3's present now for 1.3.13. > Yes, if the manual changes during the rc freeze, nothing will break, but > it's relative chaos unless it freezes again at the next 48-hour freeze > deadline. I'm open to work on "P2" manual changes in that 48-hour cycle > if they can be completed before the next rc freeze. That sounds fine to me if Manual Team are clear they have to stop by the next rc freeze. And RM has to decide if the Manual issues presented to him are "P2". I'd lobby that some of them are "P2" for the Manual we now have in rc3. Plus the ANSI/Unicode Win Manuals in rc3 are very slightly different (don't know about Mac). I hope this will all be better next time and that we can keep the Manual up-to-date in the first place. >> Another problem - bug 350 which Bill reported as PX a day or so ago: >> http://bugzilla.audacityteam.org/show_bug.cgi?id=350 >> >> >> This is a hard one to rate. If you have selected in the Device Toolbar >> then >> used the Play or Record shortcut, all other shortcuts are blocked. Most >> people would figure out to hit Stop sooner or later, but it's an >> embarrassment (IMO) and (I figure) a major problem for VI users as I >> can't >> see how they get out of it unless they can deliver a click somehow. So at >> the moment I have it as P2. That doesn't mean we have to fix it now, but >> it >> would be hard (IMO) not to release note it (which means P3) and then that >> requires rebuild anyway. > I think it's a P3. But shouldn't the "release note it" rule be for P3 or > higher? The rule is to "release note" if P2 or P3. > Why would a release note change require rebuild? I thought that problem > with README changes needing rebuild was solved already by posting to web. Sorry, had my mind more on the old system. Release noting this as a bug this wouldn't "require" rebuild, for sure. But to make the issue "more visible" there's a good case (if we rebuild anyway) for noting the issue in the "Changes" for Device Toolbar (as a need to use the mouse). Listing a bug in the Changes has worked well to cut down reports before, so might be sensible if the bug stays at P2 (meaning it will only be in 1.3.13). I think the consensus so far in the bug report (regression on 1.3.12, VI issues) is for P2. Thanks, Gale -- View this message in context: http://audacity.238276.n2.nabble.com/1-3-13rc3-freeze-tp6247268p6256115.html Sent from the audacity-devel mailing list archive at Nabble.com. |
From: Vaughan J. <va...@au...> - 2011-04-10 00:26:40
|
On 4/8/2011 9:20 PM, Gale (Audacity Team) wrote: > Vaughan wrote: >>> On 4/7/2011 4:21 PM, Gale (Audacity Team) wrote: >>> but what policy would you like on only having the current rc up on >>> Google Code? In past releases I just deleted the old ones straight away >>> without anyone objecting. >> Yes, I'm fine with that and will document it. Please delete them. Thanks. > OK we only have rc3's present now for 1.3.13. > >> Yes, if the manual changes during the rc freeze, nothing will break, but >> it's relative chaos unless it freezes again at the next 48-hour freeze >> deadline. I'm open to work on "P2" manual changes in that 48-hour cycle >> if they can be completed before the next rc freeze. > That sounds fine to me if Manual Team are clear they have to stop by the > next rc freeze. And RM has to decide if the Manual issues presented to him > are "P2". I'd lobby that some of them are "P2" for the Manual we now have in > rc3. Plus the ANSI/Unicode Win Manuals in rc3 are very slightly different > (don't know about Mac). Fair enough. But release-blocking for beta means P1 or higher, so these are not release-blocking. RM may allow them in an rc cycle, but the emphasis should be on release-blocking problems, if there are any. > > <snip>That doesn't mean we have to fix it now, but >>> it >>> would be hard (IMO) not to release note it (which means P3) and then that >>> requires rebuild anyway. >> I think it's a P3. But shouldn't the "release note it" rule be for P3 or >> higher? > The rule is to "release note" if P2 or P3. > >> Why would a release note change require rebuild? I thought that problem >> with README changes needing rebuild was solved already by posting to web. > Sorry, had my mind more on the old system. Release noting this as a bug this > wouldn't "require" rebuild, for sure. Good. Thanks. > > But to make the issue "more visible" there's a good case (if we rebuild > anyway) for noting the issue in the "Changes" for Device Toolbar (as a need > to use the mouse). I suggest putting the Changes section on the web, too. Have as little content as possible in the README. - Vaughan |
From: Vaughan J. <va...@au...> - 2011-04-07 23:14:32
|
On 4/7/2011 3:07 PM, Martyn Shaw wrote: > > > On 07/04/2011 05:25, Gale (Audacity Team) wrote: > <snip> > >> I noticed Martyn's 1.3.13rc3 again has the later msvc* dll's so I presume >> that's all he has. Did we decide what if anything to do about that? > > I didn't do steps 4.5 and 4.6 as RM said to do it like that. (Steps 4.5 ad 4.6 at http://wiki.audacityteam.org/wiki/Release_Process/Win) I was actually making a joke. Think I even had a smiley. Didn't see any correction/clarification from Gale (who wrote 4.6). The steps had turned into a discussion, and as I (mis)read it 4.5 was contradicted by 4.6, and neither was actually a step, just discussion. Rather than add 4.5 and 4.6 as steps, they should have been on Talk, and as a result of Gale's 4.6, the steps should have been fixed. Gale, I still am unclear on 4.6. Do you mean we no longer need to do *anything* special for these manifests? In that case the whole of step 4 should just be removed. I've suggested to Martyn that he rebuild the correct way, once that's clear, and re-post as rc3. Then I'll reset the rc3 48-hour timer because this was just a misunderstanding in how to build. - Vaughan |
From: Gale (A. Team) <ga...@au...> - 2011-04-08 01:16:42
|
Vaughan wrote: > I still am unclear on 4.6. Do you mean we no longer need to do *anything* > special > for these manifests? In that case the whole of step 4 should just be > removed. As I understand it, we need the "9.0.21022.8" manifest. The issue is that if we don't then distribute matching "9.0.21022.8" msvc*.dlls, then we lay ourselves open to that "error R6034" on launch, because the only way we know to stop that error is to distribute dll's that match the manifest. So "comments" 4.5 and 4.6 are correct but the step 4.4 (and audacity_unicode.iss if we used that to pull the dll's) would have to change. 4.4 says "The *.iss scripts (see "Build the Installer" below) will pick up the replacement manifest and DLLs from C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.CRT." but that path is only going to get the later dll's. On my Win 7 x64, the only place I have "9.0.21022.8" versions of the two dll's we want is: "C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.21022.8_none_bcb86ed6ac711f91" and "C:\Windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.21022.8_none_750b37ff97f4f68b" The x86 path (in my case) is the path I want. Whoever built 1.3.12 Unicode (Al?) obviously replaced the two dll's manually, but if we changed audacity_unicode iss we would have to recurse the path "C:\Windows\winsxs" I guess to make sure the dll's were found? I'm sorry I didn't remove 4.5 and 4.6 and make this crystal clear, but I didn't do so because I wasn't sure if we wanted to just replace the files manually or figure out how to change the installer script. Gale -- View this message in context: http://audacity.238276.n2.nabble.com/1-3-13rc3-freeze-tp6247268p6252151.html Sent from the audacity-devel mailing list archive at Nabble.com. |
From: Vaughan J. <va...@au...> - 2011-04-08 19:11:53
|
Putting this on -quality, too, in case other QA folks have any input. On 4/7/2011 6:16 PM, Gale (Audacity Team) wrote: > Vaughan wrote: >> I still am unclear on 4.6. Do you mean we no longer need to do *anything* >> special >> for these manifests? In that case the whole of step 4 should just be >> removed. > As I understand it, we need the "9.0.21022.8" manifest. The issue is that if > we don't then distribute matching "9.0.21022.8" msvc*.dlls, then we lay > ourselves open to that "error R6034" on launch, because the only way we know > to stop that error is to distribute dll's that match the manifest. Do we *know* that stopped the error? Al heard it was okay the way we were doing it, but thought it *might* cause the error R6034 problem (http://wiki.audacityteam.org/wiki/Release_Process/Win#Copy_other_necessities_to_release_build_folder 4.5) that afaik we hadn't replicated but heard about, rarely. Then (and I don't think I was aware of this) for 1.3.12 it was decided we go with *old* (pre-sp) versions of the DLL's, even though we had no proof using the 9.0.30729.1 SP DLL's with the hacked Manifest caused any problem, and had in fact been necessary. That means we threw out any fixes in the VC++ sp that are in the 9.0.30729.1 SP DLL's. I'm sure Microsoft had compelling reasons to patch it, and we should use the latest DLL's. I don't even know where we can get those old DLL's from a reliable source. (See below.) In short, I think that decision for 1.3.12 was unwise, and we should remove points 4.5 and 4.6, and the rc3 Martyn posted is probably fine. So let's confirm that. Can you please, on a Windows machine that has *no* msvc*90.dll's installed anywhere, install the Unicode rc3, and see if it works? If you or somebody else cannot, let me know. I'm very pressed for time, so it might be a while before I can do it. Later, it might even be worth trying it on a machine with no msvc*90.dll's, with an installer that has both the 9.0.30729.1 manifest (not hacked) and dll's. Some system patch may have fixed the problem we encountered with 1.3.8. > > So "comments" 4.5 and 4.6 are correct but the step 4.4 (and > audacity_unicode.iss if we used that to pull the dll's) would have to > change. > > 4.4 says "The *.iss scripts (see "Build the Installer" below) will pick up > the replacement manifest and DLLs from C:\Program Files\Microsoft Visual > Studio 9.0\VC\redist\x86\Microsoft.VC90.CRT." > > but that path is only going to get the later dll's. On my Win 7 x64, the > only place I have "9.0.21022.8" versions of the two dll's we want is: > > "C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.21022.8_none_bcb86ed6ac711f91" > > and > > "C:\Windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.21022.8_none_750b37ff97f4f68b" > > The x86 path (in my case) is the path I want. Those are just accidents of previous installs of the runtimes. You probably have multiple copies of the 9.0.30729.1 SP versions as well. > > Whoever built 1.3.12 Unicode (Al?) obviously replaced the two dll's > manually, but if we changed audacity_unicode iss we would have to recurse > the path "C:\Windows\winsxs" I guess to make sure the dll's were found? Unfortunately, they'd be in a different place on different builder's winsxs tree. E.g., you have two copies, probably from two installs of different apps that put them in that tree rather than in the app directory. This DLL hell is why we install them in the Audacity app directory, so at runtime, the DLL-loader doesn't wander around the winsxs tree, possibly getting DLL's that match the manifest, but that we didn't install and cannot be sure of. The .iss should get them from "C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.CRT". Those are consistent on every builder's machine (unless they installed MSVS someplace other than default). And btw, step 4.4 should say 4.4 says "The audacity_unicode.iss script..." because the ANSI build is using VC8 and all this doesn't apply, right? > > I'm sorry I didn't remove 4.5 and 4.6 and make this crystal clear, but I > didn't do so because I wasn't sure if we wanted to just replace the files > manually or figure out how to change the installer script. Neither, I think! :-) And I don't think it's possible to make DLL Hell crystal clear. :-( Thanks for trying, though. - Vaughan |
From: Leland <le...@au...> - 2011-04-08 19:47:08
|
> > So let's confirm that. Can you please, on a Windows machine that has > *no* msvc*90.dll's installed anywhere, install the Unicode rc3, and see > if it works? If you or somebody else cannot, let me know. I'm very > pressed for time, so it might be a while before I can do it. > > Later, it might even be worth trying it on a machine with no > msvc*90.dll's, with an installer that has both the 9.0.30729.1 manifest > (not hacked) and dll's. Some system patch may have fixed the problem we > encountered with 1.3.8. > I can do both of those tests. You want me to do 2k, XP, Vista, or 7? You can about Home, Prof, 32bit, or 64bit? Leland |
From: Vaughan J. <va...@au...> - 2011-04-08 21:26:23
|
On 4/8/2011 12:47 PM, Leland wrote: >> >> So let's confirm that. Can you please, on a Windows machine that has >> *no* msvc*90.dll's installed anywhere, install the Unicode rc3, and see >> if it works? If you or somebody else cannot, let me know. I'm very >> pressed for time, so it might be a while before I can do it. >> >> Later, it might even be worth trying it on a machine with no >> msvc*90.dll's, with an installer that has both the 9.0.30729.1 manifest >> (not hacked) and dll's. Some system patch may have fixed the problem we >> encountered with 1.3.8. >> > I can do both of those tests. You want me to do 2k, XP, Vista, or 7? > You can about Home, Prof, 32bit, or 64bit? > Fantastic, Leland. Gale, did "error R6034" on launch show up on a particular Windows version? - Vaughan |
From: Leland <le...@au...> - 2011-04-07 06:35:07
|
On 4/6/11 9:23 PM, Vaughan Johnson wrote: > All the rc3's except ANSI are posted. Please begin testing. > All files downloaded from googlecode. Nothing in depth, but here's what I've done and everything seemed to work fine. On Win98: Installer tested ZIP tested Generat chirp Play chirp Amplify chirp Exported AC3, AMR, FLAC, M4A, MP2, MP3, OGG, WAV, WMA, ulaw WAV Imported AC3, AMR, FLAC, M4A, MP2, MP3, OGG, WAV, WMA, ulaw WAV Saved AUP Loaded AUP Screenshot tools Help (from installer) On Win2k: Installer tested ZIP tested Generate chirp Play chirp Amplify Delay Exported WAV, MP3, OGG, M4A, AC3, WMA Imported WAV, MP3, OGG, M4A, AC3, WMA On WinXP: Installer tested ZIP tested audacity.cfg deleted VST scanning (bunches of VSTs) Generate Chirp Play Chirp Generate Click Track Amplify Chirp Several VSTs Built fullsrc, Unicode Debug and Unicode Release (Seems we have some memleaks) Detected memory leaks! Dumping objects -> {7179} normal block at 0x034E0FE0, 8 bytes long. Data: <@ > 40 A0 9B 02 00 00 00 00 c:\audacity-fullsrc-1.3.13rc3\src\audacityapp.cpp(1410) : {7178} normal block at 0x029CFC08, 4 bytes long. Data: < N > E0 0F 4E 03 c:\audacity-fullsrc-1.3.13rc3\src\audacityapp.cpp(1032) : {3166} normal block at 0x029D72F8, 40 bytes long. Data: < > D8 92 0A 01 0C 00 00 00 D4 17 00 00 00 00 00 00 {1190} normal block at 0x028B83F8, 4 bytes long. Data: < > 88 0F 00 00 {1189} normal block at 0x029B0EB0, 8 bytes long. Data: < > FC 91 0A 01 F8 83 8B 02 {1188} normal block at 0x029B28A0, 24 bytes long. Data: <p5 > 70 35 05 00 FF FF FF FF 00 00 00 00 00 00 00 00 {1187} normal block at 0x029B2830, 48 bytes long. Data: < Y > A8 59 14 01 00 00 00 00 00 00 00 00 00 00 00 00 Object dump complete. On Win7 Enterprise x64: Installer tested ZIP tested Generate chirp Play chirp Amplify GVerb Exported AIFF, FLAC, AMR Imported AIFF, FLAC, AMR Ubuntu 10.10: Built fullsrc (lib-pref=local) and minsrc Tested minsrc Generate Chirp Play Chirp Generate Click Track Amplify Delay Exported WAV, MP3, OGG, M4A, WMA Imported WAV, MP3, OGG, M4A, WMA Tested fullsrc Generate Chirp Generate Click Track Amplify Delay Exported WAV, MP3, OGG, M4A, WMA Imported WAV, MP3, OGG, M4A, WMA OSX 10.4: DMG tested ZIP tested Generate chirp Play chirp Generate Click Track Amplify Delay Exported WAV, MP3, OGG, M4A, AC3, WMA, external lame Imported WAV, MP3, OGG, M4A, AC3, WMA Built fullsrc OSX 10.6: DMG tested ZIP tested Generate chirp Play chirp Generate Click Track Amplify Delay Exported WAV, MP3, OGG, M4A, AC3, WMA, external lame, external ffmpeg Imported WAV, MP3, OGG, M4A, AC3, WMA Built fullsrc |
From: Vaughan J. <va...@au...> - 2011-04-07 07:09:17
|
Thanks, Leland! Amazing amount of testing!! - V On 4/6/2011 11:35 PM, Leland wrote: > On 4/6/11 9:23 PM, Vaughan Johnson wrote: >> All the rc3's except ANSI are posted. Please begin testing. >> > All files downloaded from googlecode. > > Nothing in depth, but here's what I've done and everything seemed to work fine. > > On Win98: > Installer tested > ZIP tested > Generat chirp > Play chirp > Amplify chirp > Exported AC3, AMR, FLAC, M4A, MP2, MP3, OGG, WAV, WMA, ulaw WAV > Imported AC3, AMR, FLAC, M4A, MP2, MP3, OGG, WAV, WMA, ulaw WAV > Saved AUP > Loaded AUP > Screenshot tools > Help (from installer) > > On Win2k: > Installer tested > ZIP tested > Generate chirp > Play chirp > Amplify > Delay > Exported WAV, MP3, OGG, M4A, AC3, WMA > Imported WAV, MP3, OGG, M4A, AC3, WMA > > On WinXP: > Installer tested > ZIP tested > audacity.cfg deleted > VST scanning (bunches of VSTs) > Generate Chirp > Play Chirp > Generate Click Track > Amplify Chirp > Several VSTs > Built fullsrc, Unicode Debug and Unicode Release > (Seems we have some memleaks) > Detected memory leaks! > Dumping objects -> > {7179} normal block at 0x034E0FE0, 8 bytes long. > Data: <@ > 40 A0 9B 02 00 00 00 00 > c:\audacity-fullsrc-1.3.13rc3\src\audacityapp.cpp(1410) : {7178} normal block at 0x029CFC08, 4 bytes long. > Data: < N > E0 0F 4E 03 > c:\audacity-fullsrc-1.3.13rc3\src\audacityapp.cpp(1032) : {3166} normal block at 0x029D72F8, 40 bytes long. > Data: < > D8 92 0A 01 0C 00 00 00 D4 17 00 00 00 00 00 00 > {1190} normal block at 0x028B83F8, 4 bytes long. > Data: < > 88 0F 00 00 > {1189} normal block at 0x029B0EB0, 8 bytes long. > Data: < > FC 91 0A 01 F8 83 8B 02 > {1188} normal block at 0x029B28A0, 24 bytes long. > Data: <p5 > 70 35 05 00 FF FF FF FF 00 00 00 00 00 00 00 00 > {1187} normal block at 0x029B2830, 48 bytes long. > Data: < Y > A8 59 14 01 00 00 00 00 00 00 00 00 00 00 00 00 > Object dump complete. > > On Win7 Enterprise x64: > Installer tested > ZIP tested > Generate chirp > Play chirp > Amplify > GVerb > Exported AIFF, FLAC, AMR > Imported AIFF, FLAC, AMR > > Ubuntu 10.10: > Built fullsrc (lib-pref=local) and minsrc > Tested minsrc > Generate Chirp > Play Chirp > Generate Click Track > Amplify > Delay > Exported WAV, MP3, OGG, M4A, WMA > Imported WAV, MP3, OGG, M4A, WMA > Tested fullsrc > Generate Chirp > Generate Click Track > Amplify > Delay > Exported WAV, MP3, OGG, M4A, WMA > Imported WAV, MP3, OGG, M4A, WMA > > OSX 10.4: > DMG tested > ZIP tested > Generate chirp > Play chirp > Generate Click Track > Amplify > Delay > Exported WAV, MP3, OGG, M4A, AC3, WMA, external lame > Imported WAV, MP3, OGG, M4A, AC3, WMA > Built fullsrc > > OSX 10.6: > DMG tested > ZIP tested > Generate chirp > Play chirp > Generate Click Track > Amplify > Delay > Exported WAV, MP3, OGG, M4A, AC3, WMA, external lame, external ffmpeg > Imported WAV, MP3, OGG, M4A, AC3, WMA > Built fullsrc > |
From: Martyn S. <mar...@gm...> - 2011-04-08 23:47:59
|
On 08/04/2011 00:21, Gale (Audacity Team) wrote: > Vaughan wrote: >>> The Google Code downloads page is a mess with rc1's, 2's and 3's. Shall >> I >>> remove the old ones as usual, and note to do this on >>> http://wiki.audacityteam.org/wiki/Release_Process#Release_Candidates? >> I'd like to avoid lots of cross-editing on that page while I'm RM. And I >> have some exceptions to some of the changes that have been made since my >> major edit. Will get to those later. > OK, but what policy would you like on only having the current rc up on > Google Code? In past releases I just deleted the old ones straight away > without anyone objecting. > > >>> However Ed has a point in that if we don't freeze the Manual, then >>> Win/Mac >>> packagers could pull slightly different versions of the Manual. We have >>> that >>> issue now in that the Extended Import Preferences are incomplete in >>> Martyn's >>> builds and a bit less incomplete in mine, and could be different again in >>> Leland's. >> I did not know about that. Aren't you all building from the same >> code?!!! That's what "freeze" means! > Of course, we're all building from the same source code. But if the Manual > is quite badly behind the code at start of rc1 which was true this time, and > allowed to catch up during the code freeze, then slightly different versions > of the Manual could be pulled according to when someone starts to build > (without e.g. someone pulling the manual and saying this is the one we're > building with). > > Another problem Please, please stop going this Gale! 'Another problem' is 'another thread'! I'm not reading below 'and another...' any more. Martyn - bug 350 which Bill reported as PX a day or so ago: > http://bugzilla.audacityteam.org/show_bug.cgi?id=350 > > This is a hard one to rate. If you have selected in the Device Toolbar then > used the Play or Record shortcut, all other shortcuts are blocked. Most > people would figure out to hit Stop sooner or later, but it's an > embarrassment (IMO) and (I figure) a major problem for VI users as I can't > see how they get out of it unless they can deliver a click somehow. So at > the moment I have it as P2. That doesn't mean we have to fix it now, but it > would be hard (IMO) not to release note it (which means P3) and then that > requires rebuild anyway. > > PS Thanks for those tests, Leland. > > > > > Gale > > > > > -- > View this message in context: http://audacity.238276.n2.nabble.com/1-3-13rc3-freeze-tp6247268p6251915.html > Sent from the audacity-devel mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Gale (A. Team) <ga...@au...> - 2011-04-09 03:12:02
|
Martyn wrote: > 'Another problem' is 'another thread'! And that's what I almost did, but then saw Leland's testing report in this thread, which you didn't pull up. So let's please have a policy on this at: http://wiki.audacityteam.org/wiki/Release_Process#Release_Candidates That only says "report bugs to audacity-devel". So, are new bugs that need discussing inside an rc freeze in their own thread, or within the thread for the particular rc freeze? I would find them most useful in the thread for the rc freeze, but clearly you prefer own thread. Gale -- View this message in context: http://audacity.238276.n2.nabble.com/1-3-13rc3-freeze-tp6247268p6256036.html Sent from the audacity-devel mailing list archive at Nabble.com. |
From: Gale A. <ga...@au...> - 2011-04-09 01:06:52
|
| From Vaughan Johnson <va...@au...> | Fri, 08 Apr 2011 12:13:45 -0700 | Subject: [Audacity-quality] [Audacity-devel] 1.3.13rc3 freeze > Putting this on -quality, too, in case other QA folks have any input. > > > On 4/7/2011 6:16 PM, Gale (Audacity Team) wrote: > > Vaughan wrote: > >> I still am unclear on 4.6. Do you mean we no longer need to do *anything* > >> special > >> for these manifests? In that case the whole of step 4 should just be > >> removed. > > As I understand it, we need the "9.0.21022.8" manifest. The issue is that if > > we don't then distribute matching "9.0.21022.8" msvc*.dlls, then we lay > > ourselves open to that "error R6034" on launch, because the only way we know > > to stop that error is to distribute dll's that match the manifest. > > Do we *know* that stopped the error? If we can believe user evidence, it would seem so. The R6034 problem was reported less often during the currency of 1.3.11 than it had been in earlier Betas, which might suggest something we had done in the code was helping. However I think it might also suggest people were migrating from the Win 7 rc's (which were previously in wide distribution) to finished versions. Anyway, during the currency of 1.3.12 I had two reports of this R6034 problem, but when I asked the users to confirm they were actually using 1.3.12, it turned out they were using 1.3.10 or 1.3.11. So rather than tell them to change to compatibility mode to Vista SP2 or XP SP3 which was the advertised workaround, I asked them to replace with the older "9.0.21022.8" dll's, and they said that stopped the error. The second case of that was what prompted me to add the note 4.6 to: http://wiki.audacityteam.org/wiki/Release_Process/Win#Copy_other_necessities_to_release_build_folder > For 1.3.12 it was decided we go with *old* (pre-sp) versions of the DLL's, > even though we had no proof using the 9.0.30729.1 SP DLL's with the > hacked Manifest caused any problem, and had in fact been necessary. > That means we threw out any fixes in the VC++ sp that are in the > 9.0.30729.1 SP DLL's. I'm sure Microsoft had compelling reasons > to patch it, and we should use the latest DLL's. Was anything found out when we researched this about the MS reasons? > I don't even know where we can get those old DLL's from a reliable > source. (See below.) > > In short, I think that decision for 1.3.12 was unwise, and we should > remove points 4.5 and 4.6, and the rc3 Martyn posted is probably fine. > > So let's confirm that. Can you please, on a Windows machine that has > *no* msvc*90.dll's installed anywhere, install the Unicode rc3, and see > if it works? If you or somebody else cannot, let me know. I'm very > pressed for time, so it might be a while before I can do it. > > Later, it might even be worth trying it on a machine with no > msvc*90.dll's, with an installer that has both the 9.0.30729.1 manifest > (not hacked) and dll's. Some system patch may have fixed the problem we > encountered with 1.3.8. > My Win 7 "Starter" 32-bit netbook (a real, but not a build machine) has no msvc*90.dll's, so yes I will do those tests. > did "error R6034" on launch show up on a particular Windows version? It was almost always Win 7, AFAIK spread across all flavours of Win 7 (with the caveat about pre-releases being apparently more afflicted) . There were isolated reports on Vista and XP as well. So if Leland as he kindly offered can test, I would suggest maybe Win Vista 32-bit and Win 7 64-bit, to give us some coverage? > And btw, step 4.4 should say 4.4 says "The audacity_unicode.iss > script..." because the ANSI build is using VC8 and all this doesn't > apply, right? Yes, well spotted. None of this applies to ANSI. Gale |
From: Gale (A. Team) <ga...@au...> - 2011-04-09 04:54:01
|
Gale wrote: > My Win 7 "Starter" 32-bit netbook (a real, but not a build machine) has no > msvc*90.dll's, so yes I will do those tests. I have no issue launching the posted 1.3.13 unicode rc3 (which has 9.0.30729.1 dll's and the hacked manifest). Then I uninstalled that build and made an installer that included the same dll's and the unhacked "C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.CRT\Microsoft.VC90.CRT.manifest". Audacity also launched fine there. However could there still be machine variabilities that might affect things somehow? For example when I installed 1.3.8 on a near virgin Win 7 x64 last year, I got the R6034 error immediately: http://audacity.238276.n2.nabble.com/Windows-7-Runtime-Error-Program-location-R6034-on-launching-Audacity-td4451902.html#a4767271 Now with Win7 fairly well patched (but without Win 7 SP1) and Visual Studio 2008 "Express" installed, I don't crash with 1.3.8. 1.3.12 worked without any reported R6034 errors (the first one that did since the issue started). It didn't have any new errors that could obviously be attributable to "dll hell" as far as I know. I kind of feel that it's working now, don't break it. Gale -- View this message in context: http://audacity.238276.n2.nabble.com/1-3-13rc3-freeze-tp6247268p6256160.html Sent from the audacity-devel mailing list archive at Nabble.com. |
From: Gale A. <ga...@au...> - 2011-04-09 15:34:21
|
| From Vaughan Johnson <va...@au...> > On 4/8/2011 6:06 PM, Gale Andrews wrote: > > > > | From Vaughan Johnson <va...@au...> > > | Fri, 08 Apr 2011 12:13:45 -0700 > > | Subject: [Audacity-quality] [Audacity-devel] 1.3.13rc3 freeze > >> Putting this on -quality, too, in case other QA folks have any input. > >> > >> > >> On 4/7/2011 6:16 PM, Gale (Audacity Team) wrote: > >>> Vaughan wrote: > >>>> I still am unclear on 4.6. Do you mean we no longer need to do *anything* > >>>> special > >>>> for these manifests? In that case the whole of step 4 should just be > >>>> removed. > >>> As I understand it, we need the "9.0.21022.8" manifest. The issue is that if > >>> we don't then distribute matching "9.0.21022.8" msvc*.dlls, then we lay > >>> ourselves open to that "error R6034" on launch, because the only way we know > >>> to stop that error is to distribute dll's that match the manifest. > >> > >> Do we *know* that stopped the error? > > > > If we can believe user evidence, it would seem so. The R6034 problem > > was reported less often during the currency of 1.3.11 than it had been > > in earlier Betas, which might suggest something we had done in the > > code was helping. However I think it might also suggest people were > > migrating from the Win 7 rc's (which were previously in wide > > distribution) to finished versions. > > No reason for us to support Win 7 rc's, right? Absolutely none. I think they would be all expired by now. But the problem was never confined to Win 7 rc's. Rc's were what most people had in the run up to (and even sometime after) Win 7 release. > > Anyway, during the currency of 1.3.12 I had two reports of this R6034 > > problem, but when I asked the users to confirm they were actually using > > 1.3.12, it turned out they were using 1.3.10 or 1.3.11. So rather than > > tell them to change to compatibility mode to Vista SP2 or XP SP3 which > > was the advertised workaround, I asked them to replace with the older > > "9.0.21022.8" dll's, and they said that stopped the error. The second > > case of that was what prompted me to add the note 4.6 to: > > http://wiki.audacityteam.org/wiki/Release_Process/Win#Copy_other_necessities_to_release_build_folder > > Okay, so not actually a problem with those 2. I think that means 2 false > reports in a year, out of 6m+ downloads. Right? If the reports were accurate (I've no reason to doubt it), that meant those users had released versions of Win 7, and the "mismatched" .dll's were directly causing Audacity 1.3.10/1.3.11 not to launch. I also see one person did the same test in 1.3.12, replacing the older dll's with the newer, and then 1.3.12 didn't launch. To the extent that people had actually upgraded from 1.3.8+ to 1.3.12, there would be a much smaller base of people still on the older versions that might make reports. So the comparison wouldn't be against 6m. What concerns me is the possible scale up if we went back to the "mismatch" in 1.3.13. Gale > >> For 1.3.12 it was decided we go with *old* (pre-sp) versions of the DLL's, > >> even though we had no proof using the 9.0.30729.1 SP DLL's with the > >> hacked Manifest caused any problem, and had in fact been necessary. > >> That means we threw out any fixes in the VC++ sp that are in the > >> 9.0.30729.1 SP DLL's. I'm sure Microsoft had compelling reasons > >> to patch it, and we should use the latest DLL's. > > > > Was anything found out when we researched this about the MS reasons? > > MS just screwed something up with Manifests vs sp1 DLL's. > > About 5 years ago I read that MS had 1,200 (yes, twelve hundred) > developers working on MSVS. There must have been at least hundreds of > fixes for them to release the VS2008 sp (no, I'm not going to research > that) and the 9.0.30729.1 SP DLL's. That's why I think it's a bad idea > to revert to the old DLL's. > > The wise tradition to work with MS products is stay away from fresh > releases and upgrade later, and then patch religiously. That's why we're > not using VS 2010. > > > > > > > >> I don't even know where we can get those old DLL's from a reliable > >> source. (See below.) > >> > >> In short, I think that decision for 1.3.12 was unwise, and we should > >> remove points 4.5 and 4.6, and the rc3 Martyn posted is probably fine. > >> > >> So let's confirm that. Can you please, on a Windows machine that has > >> *no* msvc*90.dll's installed anywhere, install the Unicode rc3, and see > >> if it works? If you or somebody else cannot, let me know. I'm very > >> pressed for time, so it might be a while before I can do it. > >> > >> Later, it might even be worth trying it on a machine with no > >> msvc*90.dll's, with an installer that has both the 9.0.30729.1 manifest > >> (not hacked) and dll's. Some system patch may have fixed the problem we > >> encountered with 1.3.8. > >> > > > > My Win 7 "Starter" 32-bit netbook (a real, but not a build machine) has no > > msvc*90.dll's, so yes I will do those tests. > > Thanks. > > > > > > > >> did "error R6034" on launch show up on a particular Windows version? > > > > It was almost always Win 7, AFAIK spread across all flavours of Win 7 > > (with the caveat about pre-releases being apparently more afflicted) . > > > > There were isolated reports on Vista and XP as well. So if Leland as > > he kindly offered can test, I would suggest maybe Win Vista 32-bit > > and Win 7 64-bit, to give us some coverage? > > > > > >> And btw, step 4.4 should say 4.4 says "The audacity_unicode.iss > >> script..." because the ANSI build is using VC8 and all this doesn't > >> apply, right? > > > > Yes, well spotted. None of this applies to ANSI. > > > > Thanks. We can resolve that when we know whether the whole step 4 is > necessary. > > - Vaughan |