HI all, I think its time for a new release. The current code base is stable and I've been building it for x86_64/linux, powerpc/linux, armhf/linux, x86_64/darwin in a Jenkins build bot. I'm pretty sure others have been building regularly on their platforms of interest. I made a first pass on an update to the changelog.html. I' also putting toether a release checklist that I will add to the git repo at some stage. Fo far that checklst contains: * Update release notes. * Make sure all files have current release year on copyright notice. * Git tag the release commit. * Upload the source tarball and flac-x.y.x-win.zip (32 and 64 bit) to: https://svn.xiph.org/releases/flac/ * Upload Windows Zip to sourceforge.net. I'm currently reading through the emails from the 1.3.1 release to see what else needs to be done. So, please test and remind me of anything I may have forgotten. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
Great stuff! For the checklist, can I suggest you also make sure all resulting FLAC files are encoded with the new date in their encoder string? As for the changelog, I have kept track of those changes that might be more interesting for end-users and developers using the format (so no build-system improvements for instance). Now, I?d be the first to admit that I haven?t always been paying attention so you are probably better positioned to decide what I?ve missed and what shouldn?t make the cut. These were on my list that I believe you haven?t covered yet: Changed the LPC order guess for a slight compression improvement, particularly for classical music http://git.xiph.org/?p=flac.git;a=commit;h=c97e057ee57d552a3ccad2d12e29b5969d04be97 Improved encoding speed on older Intel CPUs https://git.xiph.org/?p=flac.git;a=commitdiff;h=ac0b4b4cab42fdd5c010bac85bf4e63f49647e69 libFLAC: Support 64bit brword/bwword allowing FLAC__BYTES_PER_WORD to be set to 8. This is disabled by default. libFLAC: Fix potential memory leaks https://git.xiph.org/?p=flac.git;a=commit;h=15a9062609c123b56df104a575dba657c2577e0b Fixed a segmentation fault in libFLAC http://sourceforge.net/p/flac/bugs/425/ Put an upper bound on the number of seek points https://git.xiph.org/?p=flac.git;a=commitdiff;h=033af7bf1cd035772a199d07342038619c019993 Thanks, Maurits> On 8 Jan 2016, at 10:56, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > > HI all, > > I think its time for a new release. The current code base is stable > and I've been building it for x86_64/linux, powerpc/linux, armhf/linux, > x86_64/darwin in a Jenkins build bot. I'm pretty sure others have been > building regularly on their platforms of interest. > > I made a first pass on an update to the changelog.html. I' also putting > toether a release checklist that I will add to the git repo at some > stage. Fo far that checklst contains: > > * Update release notes. > * Make sure all files have current release year on copyright notice. > * Git tag the release commit. > * Upload the source tarball and flac-x.y.x-win.zip (32 and 64 bit) to: > > https://svn.xiph.org/releases/flac/ > > * Upload Windows Zip to sourceforge.net. > > I'm currently reading through the emails from the 1.3.1 release to see > what else needs to be done. > > So, please test and remind me of anything I may have forgotten. > > Cheers, > Erik > -- > ---------------------------------------------------------------------- > Erik de Castro Lopo > http://www.mega-nerd.com/ > _______________________________________________ > flac-dev mailing list > flac-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev
Erik de Castro Lopo wrote:> I'm currently reading through the emails from the 1.3.1 release to see > what else needs to be done. > > So, please test and remind me of anything I may have forgotten.Looking at the bug list at SF: <https://sourceforge.net/p/flac/bugs/284/> - "libFLAC and flac need checks where padding is specified or merged to make sure the size does not exceed the metadata block size limit of 2^24 bytes". And indeed the command like "flac.exe -P 50000000 test.wav" produces corrupted FLAC stream. Also flac.exe hangs if I try to embed very big (~30Mb) picture. I'll try to find the bugs and fix the issues.
Currently, using the Makefile.lite build system with MinGW-w64 will produce a libFLAC.a that depends on libwin_utf8_io.a. Without it, a project building with just libFLAC.a will generate undefined reference errors at link time. metadata_iterators.c: fopen_utf8, chmod_utf8, utime_utf8, _stat64_utf8, unlink_utf8, rename_utf8 stream_decoder.c: fopen_utf8 I don't think libFLAC.a should depend on another library built alongside it, much less one with only one object. Given that all other targets in the build system depend on libFLAC anyway, would it make sense to move win_utf8_io.c from src/share/win_utf8_io/ to src/libFLAC/? If so, I can provide a patch that does this. Best, Evan
Evan Ramos wrote:> If so, I can provide a patch that does this.Yes please. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
On 8 January 2016 at 11:56, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote:> I think its time for a new release. The current code base is stable > and I've been building it for x86_64/linux, powerpc/linux, armhf/linux, > x86_64/darwin in a Jenkins build bot.Yes, great idea! This is an active project with active development, we should release every now and then :-)> * Upload Windows Zip to sourceforge.net.Regarding sourceforge ... sorry in case this has been debated and discussed before, but the dominant social coding platform these days is github. New potential contributors are much more likely to already have a GitHub account than SF and contribution via GH is working really well already. My suggestion is to move issue tracking to GH and make it clear on the SF project page that issues should be filed on GH and development/contributions via GH is preferred. Also the wiki on SF should be dropped since it is not used at all. Best regards Riggs
On 01/08/16 02:56 AM, Erik de Castro Lopo wrote:> HI all, > > I think its time for a new release. The current code base is stable > and I've been building it for x86_64/linux, powerpc/linux, armhf/linux, > x86_64/darwin in a Jenkins build bot. I'm pretty sure others have been > building regularly on their platforms of interestSeems that the default binutils on OS/2 is too old to support AVX2, attached patch works around this. Not the best solution as best would be configure tests, but simple. I'll file a bug about this but it'll be a while before anything is done about it. After this the build dies with, util.c: In function 'benchmark_function': util.c:124:17: error: 'CLOCK_PROCESS_CPUTIME_ID' undeclared (first use in this function) clock_gettime (CLOCK_PROCESS_CPUTIME_ID, &start) ; Would using gettimeofday() be accurate enough? Perhaps simpler just to disable the microbench test on OS/2 as gettimeofday() would require a configure test and OS/2 is a minor platform? Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-OS-2-currently-has-too-old-of-a-binutils-to-support-.patch Type: application/x-patch Size: 904 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20160109/cd0462ce/attachment.bin
Dave Yeo wrote:> Seems that the default binutils on OS/2 is too old to support AVX2, > attached patch works around this. Not the best solution as best would be > configure tests, but simple.Are you sure that these binutils support AVX and FMA? (Currently libFLAC doesn't contain AVX and FMA instructions). If they aren't supported then it's better to include them too into #if !defined __OS2__ ... #endif.
Dave Yeo wrote:> After this the build dies with, > util.c: In function 'benchmark_function': > util.c:124:17: error: 'CLOCK_PROCESS_CPUTIME_ID' undeclared (first use > in this function) > clock_gettime (CLOCK_PROCESS_CPUTIME_ID, &start) ; > > Would using gettimeofday() be accurate enough?AS a fall back yes, but not as replacement on platforms with clock_gettime().> Perhaps simpler just to > disable the microbench test on OS/2 as gettimeofday() would require a > configure test and OS/2 is a minor platform?I would accept a patch that disables the microsbenchmark on OS/2 I would also accept one that uses gettimeofday() when clock_gettime() is not available. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/