Re: [flac-dev] New release
On Sun, Nov 23, 2014 at 02:44:00AM -0800, Erik de Castro Lopo wrote: > lvqcl wrote: > > > I have a couple of questions: > > > > 1) Do you plan to release 1.3.1 pre1, pre2 etc or just 1.3.1 w/o any > > pre-releases? > > I had not planned to do a pre-release. FWIW, considering how much code has changed since 1.3.0, I'd rather see the security bug fixed in a new 1.3.0 release, maybe with some other serious bugs like the metaflac memory corruction, and have a prerelease for 1.3.1 to test it thoroughly. I know the new release is almost ready, but if some serious bug is found in 1.3.1, a new release will have to be made anyway to not force the users to the vulnerable version. -- Miroslav Lichvar ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] FLAC 1.3.1 changelog?
MauritsVB wrote: > As we’re talking 1.3.1 release, I’ve been keeping track of a couple of > changes that I feel should be included in the changelog and that I might > as well share here. The things between brackets are just to refresh > memories, I’d leave them out of the actual changelog. Thanks Maurits, that was very useful. I added a few other things I found in the git commit log and came up with this commit: https://git.xiph.org/?p=flac.git;a=commit;h=e09ff328d4a5a480d475a2098eea1eb07bb03cef Can anyone see anything I've missed? Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] New release
lvqcl wrote: > So I think that flac-1.3.1-win.zip should contain: > > * doc/html/ folder with documentation > * win32/ folder with 32-bit flac.exe and metaflac.exe > * win64/ folder with 64-bit flac.exe and metaflac.exe > * AUTHORS, COPYING.* and README files in the root. Thanks, that is what I will build. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] FLAC 1.3.1 changelog?
On 24 Nov 2014, at 10:13, Erik de Castro Lopo wrote: > MauritsVB wrote: > >> As we’re talking 1.3.1 release, I’ve been keeping track of a couple of >> changes that I feel should be included in the changelog and that I might >> as well share here. The things between brackets are just to refresh >> memories, I’d leave them out of the actual changelog. > > Thanks Maurits, that was very useful. > > I added a few other things I found in the git commit log and came up > with this commit: > > > https://git.xiph.org/?p=flac.git;a=commit;h=e09ff328d4a5a480d475a2098eea1eb07bb03cef > > Can anyone see anything I've missed? > > Cheers, > Erik > -- > Looking good, clearly a couple of things I’d forgotten all about! Two things: 1) Shouldn’t we give Martijn van Beurden a mention for his great work on the "bartlett, bartlett_hann and triangle functions” and "New apodization functions partial_tukey and punchout_tukey” code? 2) There is a typo under ‘Build system’: "buiuld systems” Maurits ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] FLAC 1.3.1 changelog?
MauritsVB wrote: > Looking good, clearly a couple of things I’d forgotten all about! Two things: > > 1) Shouldn’t we give Martijn van Beurden a mention for his great work on the > "bartlett, bartlett_hann and triangle functions” and "New apodization > functions > partial_tukey and punchout_tukey” code? > > 2) There is a typo under ‘Build system’: "buiuld systems” Thanks. Fixed now. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] New release
Evan Ramos wrote: > Ideally the release should launch complete with the relevant binaries > or else old 1.2.1 users will not get the message when news posts hit. > Fortunately, if someone from Xiph wants to take up the call, it is > straightforward to set up both i686 and x86_64 flavors of MinGW-w64. > > 32-bit target: > http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.2/threads-posix/dwarf/ > 64-bit target: > http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.2/threads-posix/seh/ I built 32-bit flac with dwarf and sjlj. The encoding speed is the same, but flac.exe built with dwarf is ~40 kB bigger. (No difference between 64-bit sjlj and seh.) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] New release
I agree with Miroslav. It is a good practice to make a security release on a "branch" of the stable, shipped code, so that people can obtain the security fix with minimal risk to other changes. Even if the new code passes all tests fairly soon, it wouldn't hurt to have a couple of releases - one purely for security, the next with new changes in other areas. Brian Willoughby On Nov 24, 2014, at 12:47 AM, Miroslav Lichvar wrote: On Sun, Nov 23, 2014 at 02:44:00AM -0800, Erik de Castro Lopo wrote: > lvqcl wrote: > >> I have a couple of questions: >> >> 1) Do you plan to release 1.3.1 pre1, pre2 etc or just 1.3.1 w/o any >> pre-releases? > > I had not planned to do a pre-release. FWIW, considering how much code has changed since 1.3.0, I'd rather see the security bug fixed in a new 1.3.0 release, maybe with some other serious bugs like the metaflac memory corruction, and have a prerelease for 1.3.1 to test it thoroughly. I know the new release is almost ready, but if some serious bug is found in 1.3.1, a new release will have to be made anyway to not force the users to the vulnerable version. -- Miroslav Lichvar ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] New release
Miroslav Lichvar wrote: > FWIW, considering how much code has changed since 1.3.0, I don't think very much has changed. The biggest changes are Martin's new apodization window changes. > I'd rather > see the security bug fixed in a new 1.3.0 release, Err, no, rolling a new release with the same number as the old release is a bad idea. > maybe with some > other serious bugs like the metaflac memory corruction, and have a > prerelease for 1.3.1 to test it thoroughly. So, you want the two CVEs fixed, plus the metaflac memory corruption fix, but want to leave behind the numerous build system improvements? > I know the new release is almost ready, but if some serious bug is > found in 1.3.1, a new release will have to be made anyway to not force > the users to the vulnerable version. The new release has been ready for some time. ALl that was missing was me to have some spare time to start the process. As lvqcl noted back in October, Foobar2000 shipped with a git version of FLAC. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] New release
Brian Willoughby wrote: > I agree with Miroslav. It is a good practice to make a security release > on a "branch" of the stable, shipped code, so that people can obtain the > security fix with minimal risk to other changes. Even if the new code > passes all tests fairly soon, it wouldn't hurt to have a couple of releases > - one purely for security, the next with new changes in other areas. I would agree if FLAC was under active new development. However, its not. Apart from Martin's apodization window work, its been maintenance, cleanups and performance improvements. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] New release
On Sun, Nov 23, 2014 at 03:19:53PM +, maurit...@xs4all.nl wrote: > >> Considering Windows binaries: in case no new binaries are provided, please > >> at least remove the old ones from sourceforge. As can be gleaned from some > >> bug reports, support requests etc. on sourceforge, people are still > >> happily downloading old versions. > > > > Agreed. Particularly if there is a CVE issue it makes sense to stop > > suggesting 1.2.1 is the most recent version at all the places we have some > > control over. I posted a "heads up" to the Facebook page just now. No mention of a CVE, just that there is a new release coming this week. https://www.facebook.com/flac.audio It has the official website listed as https://xiph.org/flac Is anyone from the Rockbox project on this list? If the CVE issue affects playback (on architectures that can run Rockbox) then a new Rockbox release should have the new FLAC code. -- -Dec. --- (no microsoft products were used to create this message) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] New release
Declan Kelly wrote: > Is anyone from the Rockbox project on this list? > If the CVE issue affects playback (on architectures that can run > Rockbox) then a new Rockbox release should have the new FLAC code. IIRC Rockbox uses ffmpeg decoder. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] New release
On Tue, Nov 25, 2014 at 12:44:10AM +0300, lvqcl.m...@gmail.com wrote: > > > Is anyone from the Rockbox project on this list? > > IIRC Rockbox uses ffmpeg decoder. It does! http://www.rockbox.org/wiki/SoundCodecs -- -Dec. --- (no microsoft products were used to create this message) "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] New release
Declan Kelly wrote: >> IIRC Rockbox uses ffmpeg decoder. > > It does! > http://www.rockbox.org/wiki/SoundCodecs Thanks for the link. OTOH, "Seeking is implemented using routines adapted from libFLAC", so who knows. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
