[Audacity-devel] Audacity-2.1.3rc3 finds but ignores system ffmpeg libs.

[Dave Plater]

Hi, I maintain audacity for openSUSE and I'm testing packaging
Audacity-2.1.3rc3 taken from:
revision 0efe931df26da43198b03972ed50b4c3c88b2662 and although it
found system ffmpeg it tried to use a non existent local ffmpeg.
I fixed it with this patch:
Index: m4/audacity_checklib_ffmpeg.m4
===================================================================
--- m4/audacity_checklib_ffmpeg.m4.orig 2017-03-03 21:27:17.000000000 +0200
+++ m4/audacity_checklib_ffmpeg.m4 2017-03-12 11:19:27.699800789 +0200
@@ -33,6 +33,7 @@ AC_DEFUN([AUDACITY_CHECKLIB_FFMPEG], [
AC_MSG_NOTICE([FFmpeg library NOT available as system library])
fi

+
dnl see if ffmpeg is available locally, or rather that we have some
headers
dnl in lib-src/ffmpeg/ we can use.
AC_CHECK_FILE(${srcdir}/lib-src/ffmpeg/libavcodec/avcodec.h,
@@ -61,6 +62,7 @@ AC_DEFUN([AUDACITY_CONFIG_FFMPEG], [
fi
if test "$FFMPEG_USE_SYSTEM" = yes; then
FFMPEG_CFLAGS="$AVCODEC_CFLAGS $AVFORMAT_CFLAGS $AVUTIL_CFLAGS"
+ FFMPEG_LIBS="$AVCODEC_LIBS $AVFORMAT_LIBS $AVUTIL_LIBS"
if test "$dynamic_loading" = "no"; then
FFMPEG_LIBS="$AVCODEC_LIBS $AVFORMAT_LIBS $AVUTIL_LIBS"
AC_DEFINE(DISABLE_DYNAMIC_LOADING_FFMPEG, 1,
Index: configure.ac
===================================================================
--- configure.ac.orig 2017-03-03 21:27:17.000000000 +0200
+++ configure.ac 2017-03-12 11:24:11.110996939 +0200
@@ -374,8 +374,8 @@ AUDACITY_CHECKLIB_PORTAUDIO
AUDACITY_CHECKLIB_PORTSMF
AUDACITY_CHECKLIB_WIDGETEXTRA

-FFMPEG_ARGUMENT=local
-LIBFLAC_ARGUMENT=local
+FFMPEG_ARGUMENT=system
+LIBFLAC_ARGUMENT=system

dnl Decide what libraries to build with, and whether to use system or
local libraries
dnl Set variables based on choices.

Sorry about posting it, most mls don't like attachments and I don't know
how to open a bugzilla account.
Best regards
Dave Plater

[James Crook]

Thanks.

Is this problem new with RC3 or was it there in RC1 / RC2 also?

--James.

Post by Dave Plater
Hi, I maintain audacity for openSUSE and I'm testing packaging
revision 0efe931df26da43198b03972ed50b4c3c88b2662 and although it
found system ffmpeg it tried to use a non existent local ffmpeg.
Index: m4/audacity_checklib_ffmpeg.m4
===================================================================
--- m4/audacity_checklib_ffmpeg.m4.orig 2017-03-03 21:27:17.000000000 +0200
+++ m4/audacity_checklib_ffmpeg.m4 2017-03-12 11:19:27.699800789 +0200
@@ -33,6 +33,7 @@ AC_DEFUN([AUDACITY_CHECKLIB_FFMPEG], [
AC_MSG_NOTICE([FFmpeg library NOT available as system library])
fi
+
dnl see if ffmpeg is available locally, or rather that we have some
headers
dnl in lib-src/ffmpeg/ we can use.
AC_CHECK_FILE(${srcdir}/lib-src/ffmpeg/libavcodec/avcodec.h,
@@ -61,6 +62,7 @@ AC_DEFUN([AUDACITY_CONFIG_FFMPEG], [
fi
if test "$FFMPEG_USE_SYSTEM" = yes; then
FFMPEG_CFLAGS="$AVCODEC_CFLAGS $AVFORMAT_CFLAGS $AVUTIL_CFLAGS"
+ FFMPEG_LIBS="$AVCODEC_LIBS $AVFORMAT_LIBS $AVUTIL_LIBS"
if test "$dynamic_loading" = "no"; then
FFMPEG_LIBS="$AVCODEC_LIBS $AVFORMAT_LIBS $AVUTIL_LIBS"
AC_DEFINE(DISABLE_DYNAMIC_LOADING_FFMPEG, 1,
Index: configure.ac
===================================================================
--- configure.ac.orig 2017-03-03 21:27:17.000000000 +0200
+++ configure.ac 2017-03-12 11:24:11.110996939 +0200
@@ -374,8 +374,8 @@ AUDACITY_CHECKLIB_PORTAUDIO
AUDACITY_CHECKLIB_PORTSMF
AUDACITY_CHECKLIB_WIDGETEXTRA
-FFMPEG_ARGUMENT=local
-LIBFLAC_ARGUMENT=local
+FFMPEG_ARGUMENT=system
+LIBFLAC_ARGUMENT=system
dnl Decide what libraries to build with, and whether to use system or
local libraries
dnl Set variables based on choices.
Sorry about posting it, most mls don't like attachments and I don't know
how to open a bugzilla account.
Best regards
Dave Plater
------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Gale Andrews]

Thanks for testing.

/m4/audacity_checklib_ffmpeg.m4 has not changed since November
2013. It was always possible before to compile Audacity with the
previous default of system FFmpeg and system libflac, though on
some systems, compiling against system FFmpeg required use of
--disable-dynamic-loading.

So might you have forgotten --disable-dynamic-loading this time?
Are you otherwise using default ./configure CXXFLAGS="-std=gnu++11" ?

James decided he wanted to change to using local FFmpeg and local
libflac by default because he could not otherwise compile Audacity on
his Ubuntu 14.04.5 machine. I don't see that problem on my Ubuntu
14.04.5 machine, but you will have to change those two defaults if
required.



Gale

Post by James Crook
Thanks.
Is this problem new with RC3 or was it there in RC1 / RC2 also?
--James.

Post by Dave Plater
Hi, I maintain audacity for openSUSE and I'm testing packaging
revision 0efe931df26da43198b03972ed50b4c3c88b2662 and although it
found system ffmpeg it tried to use a non existent local ffmpeg.
Index: m4/audacity_checklib_ffmpeg.m4
===================================================================
--- m4/audacity_checklib_ffmpeg.m4.orig 2017-03-03 21:27:17.000000000 +0200
+++ m4/audacity_checklib_ffmpeg.m4 2017-03-12 11:19:27.699800789 +0200
@@ -33,6 +33,7 @@ AC_DEFUN([AUDACITY_CHECKLIB_FFMPEG], [
AC_MSG_NOTICE([FFmpeg library NOT available as system library])
fi
+
dnl see if ffmpeg is available locally, or rather that we have some
headers
dnl in lib-src/ffmpeg/ we can use.
AC_CHECK_FILE(${srcdir}/lib-src/ffmpeg/libavcodec/avcodec.h,
@@ -61,6 +62,7 @@ AC_DEFUN([AUDACITY_CONFIG_FFMPEG], [
fi
if test "$FFMPEG_USE_SYSTEM" = yes; then
FFMPEG_CFLAGS="$AVCODEC_CFLAGS $AVFORMAT_CFLAGS $AVUTIL_CFLAGS"
+ FFMPEG_LIBS="$AVCODEC_LIBS $AVFORMAT_LIBS $AVUTIL_LIBS"
if test "$dynamic_loading" = "no"; then
FFMPEG_LIBS="$AVCODEC_LIBS $AVFORMAT_LIBS $AVUTIL_LIBS"
AC_DEFINE(DISABLE_DYNAMIC_LOADING_FFMPEG, 1,
Index: configure.ac
===================================================================
--- configure.ac.orig 2017-03-03 21:27:17.000000000 +0200
+++ configure.ac 2017-03-12 11:24:11.110996939 +0200
@@ -374,8 +374,8 @@ AUDACITY_CHECKLIB_PORTAUDIO
AUDACITY_CHECKLIB_PORTSMF
AUDACITY_CHECKLIB_WIDGETEXTRA
-FFMPEG_ARGUMENT=local
-LIBFLAC_ARGUMENT=local
+FFMPEG_ARGUMENT=system
+LIBFLAC_ARGUMENT=system
dnl Decide what libraries to build with, and whether to use system or
local libraries
dnl Set variables based on choices.
Sorry about posting it, most mls don't like attachments and I don't know
how to open a bugzilla account.
Best regards
Dave Plater
------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Dave Plater]

Post by Gale Andrews
Thanks for testing.
/m4/audacity_checklib_ffmpeg.m4 has not changed since November
2013. It was always possible before to compile Audacity with the
previous default of system FFmpeg and system libflac, though on
some systems, compiling against system FFmpeg required use of
--disable-dynamic-loading.

I noticed that when I navigated configure.ac and the m4/macros, the flag
has never been either set or unset.

Post by Gale Andrews
So might you have forgotten --disable-dynamic-loading this time?
Are you otherwise using default ./configure CXXFLAGS="-std=gnu++11" ?

Leap:42.2/1 use gcc48 so I had to specify gcc5 to build them (after I
fixed the ffmpeg issue) Gcc5 didn't need the "-std=gnu++11" flag.
Tumbleweed uses gcc6 and is soon changing to gcc7, there I had to
specify with the "-std=c++11" flag. I will change that to the gnu variant.

Post by Gale Andrews
James decided he wanted to change to using local FFmpeg and local
libflac by default because he could not otherwise compile Audacity on
his Ubuntu 14.04.5 machine. I don't see that problem on my Ubuntu
14.04.5 machine, but you will have to change those two defaults if
required.

I have yet to sort out a wxWidgets prog/libs mismatch to run
Audacity-2.1.3b3 but that is my problem left over from a relax abi patch
applied to our wxWidgets-3_0 package which I suspect wasn't completely
applied to the nostl/containers package.
Links to the current build are in my reply to James.
Best regards
Dave Plater

[Gale Andrews]

Post by Dave Plater

Post by Gale Andrews
Thanks for testing.
/m4/audacity_checklib_ffmpeg.m4 has not changed since November
2013. It was always possible before to compile Audacity with the
previous default of system FFmpeg and system libflac, though on
some systems, compiling against system FFmpeg required use of
--disable-dynamic-loading.

I noticed that when I navigated configure.ac and the m4/macros, the flag
has never been either set or unset.

Then it presumably isn't set.

Could you try passing --disable-dynamic-loading.to configure but not
patching m4/audacity_checklib_ffmpeg.m4 ? That should work, as far
as I know.

--disable-dynamic-loading being required on some systems to build
Audacity with system FFmpeg isn't a new issue, so it wouldn't block
release.


Gale

Post by Dave Plater

Post by Gale Andrews
So might you have forgotten --disable-dynamic-loading this time?
Are you otherwise using default ./configure CXXFLAGS="-std=gnu++11" ?

Leap:42.2/1 use gcc48 so I had to specify gcc5 to build them (after I
fixed the ffmpeg issue) Gcc5 didn't need the "-std=gnu++11" flag.
Tumbleweed uses gcc6 and is soon changing to gcc7, there I had to
specify with the "-std=c++11" flag. I will change that to the gnu variant.

Post by Gale Andrews
James decided he wanted to change to using local FFmpeg and local
libflac by default because he could not otherwise compile Audacity on
his Ubuntu 14.04.5 machine. I don't see that problem on my Ubuntu
14.04.5 machine, but you will have to change those two defaults if
required.

I have yet to sort out a wxWidgets prog/libs mismatch to run
Audacity-2.1.3b3 but that is my problem left over from a relax abi patch
applied to our wxWidgets-3_0 package which I suspect wasn't completely
applied to the nostl/containers package.
Links to the current build are in my reply to James.
Best regards
Dave Plater
------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Dave Plater]

Post by Gale Andrews
Could you try passing --disable-dynamic-loading.to configure but not
patching m4/audacity_checklib_ffmpeg.m4 ? That should work, as far
as I know.
--disable-dynamic-loading being required on some systems to build
Audacity with system FFmpeg isn't a new issue, so it wouldn't block
release.

No it doesn't work:
checking for AVCODEC... yes
checking for AVFORMAT... yes
checking for AVUTIL... yes
configure: FFmpeg library available as system library
checking for ./lib-src/ffmpeg/libavcodec/avcodec.h... no
checking for ./lib-src/ffmpeg/libavformat/avformat.h... no
configure: ffmpeg library is NOT available in the local tree

and
configure: error: You requested using the local libraries for FFMPEG but
they are not available

Dave

[Dave Plater]

Post by Gale Andrews
Then it presumably isn't set.
Could you try passing --disable-dynamic-loading.to configure but not
patching m4/audacity_checklib_ffmpeg.m4 ? That should work, as far
as I know.
--disable-dynamic-loading being required on some systems to build
Audacity with system FFmpeg isn't a new issue, so it wouldn't block
release.
Gale

Finally got the wxWidgets mess fixed, patched version indicated as
Audacity 2.1.3-alpha-Mar 14 2017 builds and functions on openSUSE as
expected.
Regards
Dave

[Dave Plater]

Post by Dave Plater

Post by Gale Andrews
Then it presumably isn't set.
Could you try passing --disable-dynamic-loading.to configure but not
patching m4/audacity_checklib_ffmpeg.m4 ? That should work, as far
as I know.
--disable-dynamic-loading being required on some systems to build
Audacity with system FFmpeg isn't a new issue, so it wouldn't block
release.
Gale

Finally got the wxWidgets mess fixed, patched version indicated as
Audacity 2.1.3-alpha-Mar 14 2017 builds and functions on openSUSE as
expected.
Regards
Dave

Two points Flac needs to have a minimum version specified, it didn't
build with stock Leap:42.2 version 1.3.0, I used 1.3.2 and it would be
nice if configure, after finding lv2, gave a hint that lilv and suil-0
are also needed. I only realized that system lv2 also required them
while looking through m4 macros.
Best regards
Dave

[James Crook]

Post by Dave Plater

Post by Dave Plater

Post by Gale Andrews
Then it presumably isn't set.
Could you try passing --disable-dynamic-loading.to configure but not
patching m4/audacity_checklib_ffmpeg.m4 ? That should work, as far
as I know.
--disable-dynamic-loading being required on some systems to build
Audacity with system FFmpeg isn't a new issue, so it wouldn't block
release.
Gale

Finally got the wxWidgets mess fixed, patched version indicated as
Audacity 2.1.3-alpha-Mar 14 2017 builds and functions on openSUSE as
expected.
Regards
Dave

Two points Flac needs to have a minimum version specified, it didn't
build with stock Leap:42.2 version 1.3.0, I used 1.3.2 and it would be
nice if configure, after finding lv2, gave a hint that lilv and suil-0
are also needed. I only realized that system lv2 also required them
while looking through m4 macros.
Best regards
Dave

I'm a windows developer and very much at sea still in the automake
world. Would really welcome your help with it. I want to be careful
that changes improve things generally, so changes that make things worse
on ubuntu but better on openSUSE aren't on.

Is the current tarball (RC4) 'good' for openSUSE. If so, I would like
to go with it, and then do a tidy up, and get some help understanding of
what is going on in automake from you, so that we use it properly and in
a way that works well for ubuntu and openSUSE. I see we have a lot of
deprecated usages, which reflects history. I would like to clean those up.

--James.

[Gale Andrews]

Post by Dave Plater

Post by Dave Plater

Post by Gale Andrews
Then it presumably isn't set.
Could you try passing --disable-dynamic-loading.to configure but not
patching m4/audacity_checklib_ffmpeg.m4 ? That should work, as far
as I know.
--disable-dynamic-loading being required on some systems to build
Audacity with system FFmpeg isn't a new issue, so it wouldn't block
release.
Gale

Finally got the wxWidgets mess fixed, patched version indicated as
Audacity 2.1.3-alpha-Mar 14 2017 builds and functions on openSUSE as
expected.
Regards
Dave

Two points Flac needs to have a minimum version specified, it didn't
build with stock Leap:42.2 version 1.3.0, I used 1.3.2

The libflac currently shipped with Audacity is 1.3.1, which does compile
with Audacity.

On Ubuntu 14.04 my system libflac is claimed as "1.3.0-2ubuntu0.14.04.1"
which again I can build Audacity against.

I am guessing James has the same system libflac, so something else than
flac version "might" be the cause of Audacity build problems.

Thanks for your input.


Gale

Post by Dave Plater
and it would be nice if configure, after finding lv2, gave a hint that lilv and suil-0
are also needed. I only realized that system lv2 also required them
while looking through m4 macros.
Best regards
Dave
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Dave Plater]

Post by Gale Andrews
The libflac currently shipped with Audacity is 1.3.1, which does compile
with Audacity.
On Ubuntu 14.04 my system libflac is claimed as "1.3.0-2ubuntu0.14.04.1"
which again I can build Audacity against.
I am guessing James has the same system libflac, so something else than
flac version "might" be the cause of Audacity build problems.

I get an undefined symbol error with 1.3.0, I will investigate this
later, it's possibly something in our flac build. My main task is to get
audacity build 100% before you release 2.1.3. I've already fixed the
wxWidgets containers package I created for audacity so far.

Dave

[Dave Plater]

Post by Gale Andrews
The libflac currently shipped with Audacity is 1.3.1, which does compile
with Audacity.
On Ubuntu 14.04 my system libflac is claimed as "1.3.0-2ubuntu0.14.04.1"
which again I can build Audacity against.
I am guessing James has the same system libflac, so something else than
flac version "might" be the cause of Audacity build problems.
Thanks for your input.
Gale

Using revision #2fef7f34b82e1a14af4c4b27f486ce9d13fe3086 and no patch
system ffmpeg is used but this happens:
checking for FLAC... no
checking for FLAC... yes
configure: FLAC libraries are available as system libraries
checking for ./lib-src/libflac/include/FLAC/format.h... yes
checking for ./lib-src/libflac/include/FLAC++/decoder.h... yes
configure: FLAC libraries are available in this source tree
and
configure: disabling LIBFLAC at your request

Is your Audacity not building against local libflac perhaps?

Dave

[Dave Plater]

Ignore the last message, I had a --without-libflac flag left behind. I
retried building with openSUSE's flac-1.3.0 and I get this error:
ondemand/ODDecodeFlacTask.cpp: In member function 'virtual void
ODFLACFile::metadata_callback(const FLAC__StreamMetadata*)':
ondemand/ODDecodeFlacTask.cpp:84:12: error: 'FLAC__MAX_METADATA_TYPE'
was not declared in this scope
case FLAC__MAX_METADATA_TYPE: // quiet compiler warning with
this line
I'm happy to use flac-1.3.2
Regards
Dave

Post by Dave Plater

Post by Gale Andrews
The libflac currently shipped with Audacity is 1.3.1, which does compile
with Audacity.
On Ubuntu 14.04 my system libflac is claimed as "1.3.0-2ubuntu0.14.04.1"
which again I can build Audacity against.
I am guessing James has the same system libflac, so something else than
flac version "might" be the cause of Audacity build problems.
Thanks for your input.
Gale

Using revision #2fef7f34b82e1a14af4c4b27f486ce9d13fe3086 and no patch
checking for FLAC... no
checking for FLAC... yes
configure: FLAC libraries are available as system libraries
checking for ./lib-src/libflac/include/FLAC/format.h... yes
checking for ./lib-src/libflac/include/FLAC++/decoder.h... yes
configure: FLAC libraries are available in this source tree
and
configure: disabling LIBFLAC at your request
Is your Audacity not building against local libflac perhaps?
Dave

[Dave Plater]

Post by James Crook
Thanks.
Is this problem new with RC3 or was it there in RC1 / RC2 also?

From Gale's comment I would say yes. I never noticed a problem with 2.1.2

Post by James Crook
--James.

This package is based on the stable 2.1.2 release, with the revision you
supplied in the " Two week pause before RC3" thread.
I'm getting the package ready before 2.1.3's release and it will be
available in Tumbleweed and via Packman for the other current openSUSE
releases.
You can find build logs etc at:
https://build.opensuse.org/package/show/home:plater/audacity
click on the different succeeded's in the build results and then on
"download logfile" for a full log.
Any feedback will be appreciated.

[James Crook]

Thanks David.

This time round I am going to leave it to Gale to decide what priority
to give the problem. P1 blocks, and if Gale gives the issue you
reported a P1 we would do an RC4. Otherwise we will improve on this at
the start of the release cycle for 2.2.0 (next release after 2.1.3).

--James.

Post by Dave Plater

Post by James Crook
Thanks.
Is this problem new with RC3 or was it there in RC1 / RC2 also?

From Gale's comment I would say yes. I never noticed a problem with 2.1.2

Post by James Crook
--James.

This package is based on the stable 2.1.2 release, with the revision you
supplied in the " Two week pause before RC3" thread.
I'm getting the package ready before 2.1.3's release and it will be
available in Tumbleweed and via Packman for the other current openSUSE
releases.
https://build.opensuse.org/package/show/home:plater/audacity
click on the different succeeded's in the build results and then on
"download logfile" for a full log.
Any feedback will be appreciated.

[Gale Andrews]

Post by James Crook
Thanks David.
This time round I am going to leave it to Gale to decide what priority
to give the problem. P1 blocks, and if Gale gives the issue you
reported a P1 we would do an RC4. Otherwise we will improve on this at
the start of the release cycle for 2.2.0 (next release after 2.1.3).

I've offered my opinion before that distros (and even some users) will
want to build with system libflac and system FFmpeg. If we can't
actually build like that, I feel that would be a P1 regression.

James, could you try just running

./configure --with-ffmpeg=system --with-libflac=system ?

The configure output on my Ubuntu 14.04 machine still says that
libflac and FFmpeg are using LOCAL libraries. So I'm stuck.

But I can change libsndfile to local by using --with-libsndfile=local.


Gale

Post by James Crook

Post by Dave Plater

Post by James Crook
Thanks.
Is this problem new with RC3 or was it there in RC1 / RC2 also?

From Gale's comment I would say yes. I never noticed a problem with 2.1.2

Post by James Crook
--James.

This package is based on the stable 2.1.2 release, with the revision you
supplied in the " Two week pause before RC3" thread.
I'm getting the package ready before 2.1.3's release and it will be
available in Tumbleweed and via Packman for the other current openSUSE
releases.
https://build.opensuse.org/package/show/home:plater/audacity
click on the different succeeded's in the build results and then on
"download logfile" for a full log.
Any feedback will be appreciated.

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[James Crook]

Post by Gale Andrews

Post by James Crook
Thanks David.
This time round I am going to leave it to Gale to decide what priority
to give the problem. P1 blocks, and if Gale gives the issue you
reported a P1 we would do an RC4. Otherwise we will improve on this at
the start of the release cycle for 2.2.0 (next release after 2.1.3).

I've offered my opinion before that distros (and even some users) will
want to build with system libflac and system FFmpeg. If we can't
actually build like that, I feel that would be a P1 regression.
James, could you try just running
./configure --with-ffmpeg=system --with-libflac=system ?

Local still for me, even though I ask for system. So sounds like a P1.

I don't intend to redo the windows and mac RC3s for this though. It
would only be cosmetic so that they all have the same commit ID.

I'll undo my change, and (when testing) on my machine use
--with-ffmpeg=local and --with-libflac=local and we can get to the
bottom of why I can't use =system on my machine some other time - if on
your machine it works.

--James.

[James Crook]

OK. I've modified the tarball, so we have an RC4 tarball now on fosshub
audacity-devel.

I've checked that I can

./configure CXXFLAGS="-std=gnu++11" --with-ffmpeg=system --with-libflac=system
./configure CXXFLAGS="-std=gnu++11" --with-ffmpeg=local --with-libflac=local

I get the libs configured as system/local respectively. As before, I can make with local, but not with system.

--james.

Post by James Crook

Post by Gale Andrews

Post by James Crook
Thanks David.
This time round I am going to leave it to Gale to decide what priority
to give the problem. P1 blocks, and if Gale gives the issue you
reported a P1 we would do an RC4. Otherwise we will improve on this at
the start of the release cycle for 2.2.0 (next release after 2.1.3).

I've offered my opinion before that distros (and even some users) will
want to build with system libflac and system FFmpeg. If we can't
actually build like that, I feel that would be a P1 regression.
James, could you try just running
./configure --with-ffmpeg=system --with-libflac=system ?

Local still for me, even though I ask for system. So sounds like a P1.
I don't intend to redo the windows and mac RC3s for this though. It
would only be cosmetic so that they all have the same commit ID.
I'll undo my change, and (when testing) on my machine use
--with-ffmpeg=local and --with-libflac=local and we can get to the
bottom of why I can't use =system on my machine some other time - if on
your machine it works.
--James.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Gale Andrews]

Post by James Crook

Post by Gale Andrews

Post by James Crook
Thanks David.
This time round I am going to leave it to Gale to decide what priority
to give the problem. P1 blocks, and if Gale gives the issue you
reported a P1 we would do an RC4. Otherwise we will improve on this at
the start of the release cycle for 2.2.0 (next release after 2.1.3).

I've offered my opinion before that distros (and even some users) will
want to build with system libflac and system FFmpeg. If we can't
actually build like that, I feel that would be a P1 regression.
James, could you try just running
./configure --with-ffmpeg=system --with-libflac=system ?

Local still for me, even though I ask for system. So sounds like a P1.
I don't intend to redo the windows and mac RC3s for this though. It
would only be cosmetic so that they all have the same commit ID.
I'll undo my change, and (when testing) on my machine use
--with-ffmpeg=local and --with-libflac=local and we can get to the
bottom of why I can't use =system on my machine some other time - if on
your machine it works.

Yes I can build with default ./configure and get system libflac
and system FFmpeg configured now.

A generated configure file will have to be committed, I guess.

Can your version script distinguish a different final release ID
for Linux compared to Windows / Mac?



Gale

[James Crook]

Post by Gale Andrews

Post by James Crook

Post by Gale Andrews

Post by James Crook
Thanks David.
This time round I am going to leave it to Gale to decide what priority
to give the problem. P1 blocks, and if Gale gives the issue you
reported a P1 we would do an RC4. Otherwise we will improve on this at
the start of the release cycle for 2.2.0 (next release after 2.1.3).

I've offered my opinion before that distros (and even some users) will
want to build with system libflac and system FFmpeg. If we can't
actually build like that, I feel that would be a P1 regression.
James, could you try just running
./configure --with-ffmpeg=system --with-libflac=system ?

Local still for me, even though I ask for system. So sounds like a P1.
I don't intend to redo the windows and mac RC3s for this though. It
would only be cosmetic so that they all have the same commit ID.
I'll undo my change, and (when testing) on my machine use
--with-ffmpeg=local and --with-libflac=local and we can get to the
bottom of why I can't use =system on my machine some other time - if on
your machine it works.

Yes I can build with default ./configure and get system libflac
and system FFmpeg configured now.
A generated configure file will have to be committed, I guess.

Why so? We EXPECT builders using the tarball to run ./confiugre.
I'm not averse to committing it after we release 2.1.3, but am not
seeing it as necessary for 2.1.3.

Post by Gale Andrews
Can your version script distinguish a different final release ID
for Linux compared to Windows / Mac?

Most linux builders don't currently know to run the
audacity/mac/get_gitident.sh, script and they probably won't realise
their responsibility to revert it after compiling, to make sure the
wrong id isn't used with a modded version. So Linux builds from source
are likely to have no gitident, just the version number and timestamp.
They will therefore appear as 'builds built from source, not by Audacity
team'. IF a maintainer like David wants to work with us on this, he can
provide the query string that openSUSE's build uses when doing
check-version, and we can then add that in to our script and say
'Offical openSUSE 2.1.3 version. Your version is up to date'. The
timestamp will be enough. It doesn't have to have the gitidnet.

Note that we also have enough information to say whether a version is
mac or windows or linux when it is a known build.

--James.

[Gale Andrews]

Post by James Crook

Post by Gale Andrews

Post by James Crook

Post by Gale Andrews

Post by James Crook
Thanks David.
This time round I am going to leave it to Gale to decide what priority
to give the problem. P1 blocks, and if Gale gives the issue you
reported a P1 we would do an RC4. Otherwise we will improve on this at
the start of the release cycle for 2.2.0 (next release after 2.1.3).

I've offered my opinion before that distros (and even some users) will
want to build with system libflac and system FFmpeg. If we can't
actually build like that, I feel that would be a P1 regression.
James, could you try just running
./configure --with-ffmpeg=system --with-libflac=system ?

Local still for me, even though I ask for system. So sounds like a P1.
I don't intend to redo the windows and mac RC3s for this though. It
would only be cosmetic so that they all have the same commit ID.
I'll undo my change, and (when testing) on my machine use
--with-ffmpeg=local and --with-libflac=local and we can get to the
bottom of why I can't use =system on my machine some other time - if on
your machine it works.

Yes I can build with default ./configure and get system libflac
and system FFmpeg configured now.
A generated configure file will have to be committed, I guess.

Why so?

Why did you do it yourself in this commit:
https://github.com/audacity/audacity/commit/77ceb6a ?

Post by James Crook
We EXPECT builders using the tarball to run ./confiugre.

My understanding was that we were supposed to commit a
regenerated configure when we change configure.ac, for those
users continuing to build in the same tree. Otherwise they all
have to remember or realise to run aclocal and autoreconf.

Post by James Crook
I'm not averse to committing it include the after we release 2.1.3, but am not
seeing it as necessary for 2.1.3.

Post by Gale Andrews
Can your version script distinguish a different final release ID
for Linux compared to Windows / Mac?

Most linux builders don't currently know to run the
audacity/mac/get_gitident.sh, script and they probably won't realise
their responsibility to revert it after compiling, to make sure the
wrong id isn't used with a modded version. So Linux builds from source
are likely to have no gitident, just the version number and timestamp.
They will therefore appear as 'builds built from source, not by Audacity
team'. IF a maintainer like David wants to work with us on this, he can
provide the query string that openSUSE's build uses when doing
check-version, and we can then add that in to our script and say
'Offical openSUSE 2.1.3 version. Your version is up to date'. The
timestamp will be enough. It doesn't have to have the gitidnet.
Note that we also have enough information to say whether a version is
mac or windows or linux when it is a known build.

Obviously Windows and Mac matter the most for the version check.

But if I do build in the gitident, I would hope a final 2.1.3 tarball at
2fef7f3 as currently would show me the "Congratulations. You are
up to date." message, as the 2.1.2 source tarball does.

Anyway I would suggest for support workers that the 2.1.3 Release
Notes mentions the gitident for Windows/Mac and Linux. This might
be useful for users too, even for the normal case where the ident
would be the same for each platform.


Gale

Post by James Crook
--James.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[James Crook]

To be clear....

I did not and do not intend to include the gitident in the tarball. The
problem is that, if I do, then self builders who may build and also
modify will appear to have a known version when they don't. An example
of that was Debian building non wx3 Audacity with wx3 with all the
problems that follow from that.

Maintainers for other distros who are in communication with us, can
build and release a binary version. If they tell us what they have
done, we can then include the version they choose in our server script -
whether or not it has a gitident.

I think for 2.2.0 the get_gitident.sh script should also include a
message that 'you are responsible for updating the gitident - if you
make any modifications to the source. Please also share your
modifications with Audacity team.'. Once we do that it will be more OK
to publicise the get_gitident.sh script better.

Post by Gale Andrews

Post by James Crook

Post by Gale Andrews

Post by James Crook

Post by Gale Andrews

Post by James Crook
Thanks David.
This time round I am going to leave it to Gale to decide what priority
to give the problem. P1 blocks, and if Gale gives the issue you
reported a P1 we would do an RC4. Otherwise we will improve on this at
the start of the release cycle for 2.2.0 (next release after 2.1.3).

I've offered my opinion before that distros (and even some users) will
want to build with system libflac and system FFmpeg. If we can't
actually build like that, I feel that would be a P1 regression.
James, could you try just running
./configure --with-ffmpeg=system --with-libflac=system ?

Local still for me, even though I ask for system. So sounds like a P1.
I don't intend to redo the windows and mac RC3s for this though. It
would only be cosmetic so that they all have the same commit ID.
I'll undo my change, and (when testing) on my machine use
--with-ffmpeg=local and --with-libflac=local and we can get to the
bottom of why I can't use =system on my machine some other time - if on
your machine it works.

Yes I can build with default ./configure and get system libflac
and system FFmpeg configured now.
A generated configure file will have to be committed, I guess.

Why so?

https://github.com/audacity/audacity/commit/77ceb6a ?

Post by James Crook
We EXPECT builders using the tarball to run ./confiugre.

My understanding was that we were supposed to commit a
regenerated configure when we change configure.ac, for those
users continuing to build in the same tree. Otherwise they all
have to remember or realise to run aclocal and autoreconf.

Post by James Crook
I'm not averse to committing it include the after we release 2.1.3, but am not
seeing it as necessary for 2.1.3.

Post by Gale Andrews
Can your version script distinguish a different final release ID
for Linux compared to Windows / Mac?

Most linux builders don't currently know to run the
audacity/mac/get_gitident.sh, script and they probably won't realise
their responsibility to revert it after compiling, to make sure the
wrong id isn't used with a modded version. So Linux builds from source
are likely to have no gitident, just the version number and timestamp.
They will therefore appear as 'builds built from source, not by Audacity
team'. IF a maintainer like David wants to work with us on this, he can
provide the query string that openSUSE's build uses when doing
check-version, and we can then add that in to our script and say
'Offical openSUSE 2.1.3 version. Your version is up to date'. The
timestamp will be enough. It doesn't have to have the gitidnet.
Note that we also have enough information to say whether a version is
mac or windows or linux when it is a known build.

Obviously Windows and Mac matter the most for the version check.
But if I do build in the gitident, I would hope a final 2.1.3 tarball at
2fef7f3 as currently would show me the "Congratulations. You are
up to date." message, as the 2.1.2 source tarball does.
Anyway I would suggest for support workers that the 2.1.3 Release
Notes mentions the gitident for Windows/Mac and Linux. This might
be useful for users too, even for the normal case where the ident
would be the same for each platform.
Gale

[Gale Andrews]

Post by James Crook
To be clear....
I did not and do not intend to include the gitident in the tarball. The
problem is that, if I do, then self builders who may build and also
modify will appear to have a known version when they don't.

I have not suggested that we (you) should include the gitident in
the tarball.

Post by James Crook
An example of that was Debian building non wx3 Audacity with wx3 with all the
problems that follow from that.
Maintainers for other distros who are in communication with us, can
build and release a binary version. If they tell us what they have
done, we can then include the version they choose in our server script -
whether or not it has a gitident.
I think for 2.2.0 the get_gitident.sh script should also include a
message that 'you are responsible for updating the gitident - if you
make any modifications to the source. Please also share your
modifications with Audacity team.'. Once we do that it will be more OK
to publicise the get_gitident.sh script better.

Even then, If the user makes some mod of their own but doesn't commit
it to GitHub, there is no gitident they can update to, is there?

A git status check could indicate changes to *in files that might not be
changes to the code, so that is no guide.

Perhaps you're correct in thinking there is little value in figuring out
the Audacity version on Linux if the user builds it.


Gale

Post by James Crook

Post by Gale Andrews

Post by James Crook

Post by Gale Andrews

Post by James Crook

Post by Gale Andrews

Post by James Crook
Thanks David.
This time round I am going to leave it to Gale to decide what priority
to give the problem. P1 blocks, and if Gale gives the issue you
reported a P1 we would do an RC4. Otherwise we will improve on this at
the start of the release cycle for 2.2.0 (next release after 2.1.3).

I've offered my opinion before that distros (and even some users) will
want to build with system libflac and system FFmpeg. If we can't
actually build like that, I feel that would be a P1 regression.
James, could you try just running
./configure --with-ffmpeg=system --with-libflac=system ?

Local still for me, even though I ask for system. So sounds like a P1.
I don't intend to redo the windows and mac RC3s for this though. It
would only be cosmetic so that they all have the same commit ID.
I'll undo my change, and (when testing) on my machine use
--with-ffmpeg=local and --with-libflac=local and we can get to the
bottom of why I can't use =system on my machine some other time - if on
your machine it works.

Yes I can build with default ./configure and get system libflac
and system FFmpeg configured now.
A generated configure file will have to be committed, I guess.

Why so?

https://github.com/audacity/audacity/commit/77ceb6a ?

Post by James Crook
We EXPECT builders using the tarball to run ./confiugre.

My understanding was that we were supposed to commit a
regenerated configure when we change configure.ac, for those
users continuing to build in the same tree. Otherwise they all
have to remember or realise to run aclocal and autoreconf.

Post by James Crook
I'm not averse to committing it include the after we release 2.1.3, but am not
seeing it as necessary for 2.1.3.

Post by Gale Andrews
Can your version script distinguish a different final release ID
for Linux compared to Windows / Mac?

Most linux builders don't currently know to run the
audacity/mac/get_gitident.sh, script and they probably won't realise
their responsibility to revert it after compiling, to make sure the
wrong id isn't used with a modded version. So Linux builds from source
are likely to have no gitident, just the version number and timestamp.
They will therefore appear as 'builds built from source, not by Audacity
team'. IF a maintainer like David wants to work with us on this, he can
provide the query string that openSUSE's build uses when doing
check-version, and we can then add that in to our script and say
'Offical openSUSE 2.1.3 version. Your version is up to date'. The
timestamp will be enough. It doesn't have to have the gitidnet.
Note that we also have enough information to say whether a version is
mac or windows or linux when it is a known build.

Obviously Windows and Mac matter the most for the version check.
But if I do build in the gitident, I would hope a final 2.1.3 tarball at
2fef7f3 as currently would show me the "Congratulations. You are
up to date." message, as the 2.1.2 source tarball does.
Anyway I would suggest for support workers that the 2.1.3 Release
Notes mentions the gitident for Windows/Mac and Linux. This might
be useful for users too, even for the normal case where the ident
would be the same for each platform.
Gale

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Dave Plater]

Post by James Crook
Most linux builders don't currently know to run the
audacity/mac/get_gitident.sh, script and they probably won't realise

audacity/mac/scripts/get_gitident.sh but the downloaded tarball is
stripped of .git

Post by James Crook
their responsibility to revert it after compiling, to make sure the
wrong id isn't used with a modded version. So Linux builds from source
are likely to have no gitident, just the version number and timestamp.

I have to patch out timestamps to prevent excessive rebuilds in our
automatic build system, the 2.1.2 patch didn't apply so I'm leaving that
till last.

Post by James Crook
They will therefore appear as 'builds built from source, not by Audacity
team'. IF a maintainer like David wants to work with us on this, he can
provide the query string that openSUSE's build uses when doing
check-version, and we can then add that in to our script and say
'Offical openSUSE 2.1.3 version. Your version is up to date'. The
timestamp will be enough. It doesn't have to have the gitidnet.
Note that we also have enough information to say whether a version is
mac or windows or linux when it is a known build.
--James.

Our %configure macro used in the spec file passes
--host=x86_64-suse-linux-gnu and --build=x86_64-suse-linux-gnu to configure.
/etc/os/release contains all the info this is my current system:
cat /etc/os-release
NAME="openSUSE Leap"
VERSION="42.2"
ID=opensuse
ID_LIKE="suse"
VERSION_ID="42.2"
PRETTY_NAME="openSUSE Leap 42.2"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:42.2"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"

Currently the Commit Id: field in Build information gives "No revision
identifier was provided" but I use the full git revision code in the
spec file to automatically download the source tarball so I can pass it
to configure.
Best regards
Dave

[James Crook]

Post by Dave Plater

Post by James Crook
Most linux builders don't currently know to run the
audacity/mac/get_gitident.sh, script and they probably won't realise

audacity/mac/scripts/get_gitident.sh but the downloaded tarball is
stripped of .git

Agreed. It serves no useful purpose in the tarball and could be removed.

Post by Dave Plater

Post by James Crook
their responsibility to revert it after compiling, to make sure the
wrong id isn't used with a modded version. So Linux builds from source
are likely to have no gitident, just the version number and timestamp.

I have to patch out timestamps to prevent excessive rebuilds in our
automatic build system, the 2.1.2 patch didn't apply so I'm leaving that
till last.

So you're removing the timestring, &Time=Mar8201714:01:59. If you do
you can put whatever arguments you like on the URL instead, e.g.

&SUSEBuildID=1234
or just
&SUSE

Our script for 'check version' is doing simple string matching. So you
can tell us you would like:

'from_ver=2.1.3&SUSEBuildID=1234'

to give the message 'You are using the latest version of Audacity
released for SUSE' and

'from_ver=2.1.3&SUSEBuildID=1233'

to give the message 'A more recent version of Audacity for SUSE is
available'

We can then just update our script on our server wit those strings/messages.

Post by Dave Plater

Post by James Crook
They will therefore appear as 'builds built from source, not by Audacity
team'. IF a maintainer like David wants to work with us on this, he can
provide the query string that openSUSE's build uses when doing
check-version, and we can then add that in to our script and say
'Offical openSUSE 2.1.3 version. Your version is up to date'. The
timestamp will be enough. It doesn't have to have the gitidnet.
Note that we also have enough information to say whether a version is
mac or windows or linux when it is a known build.
--James.

Our %configure macro used in the spec file passes
--host=x86_64-suse-linux-gnu and --build=x86_64-suse-linux-gnu to configure.
cat /etc/os-release
NAME="openSUSE Leap"
VERSION="42.2"
ID=opensuse
ID_LIKE="suse"
VERSION_ID="42.2"
PRETTY_NAME="openSUSE Leap 42.2"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:42.2"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
Currently the Commit Id: field in Build information gives "No revision
identifier was provided" but I use the full git revision code in the
spec file to automatically download the source tarball so I can pass it
to configure.

So, let me check, you get the source zip from github, using the git
revision code, patch the source with your patches, run our
maketarball.sh and then run configure on that?

If so then this could make sense as URL arguments:

?from_ver=2.1.3&CommitId=ffe4aa&SUSEPatchID=38adcb

It is up to you if you to what extent you use our 'check for updates'
approach. If you use URL arguments like:

?from_ver=2.1.3&CommitId=ffe4aa&SUSE
or even:
?from_ver=2.1.3&SUSE

We can still tell your patched builds apart from ours.

--James.

[Dave Plater]

Post by James Crook

Post by Dave Plater

Post by James Crook
Most linux builders don't currently know to run the
audacity/mac/get_gitident.sh, script and they probably won't realise

audacity/mac/scripts/get_gitident.sh but the downloaded tarball is
stripped of .git

Agreed. It serves no useful purpose in the tarball and could be removed.

Post by Dave Plater

Post by James Crook
their responsibility to revert it after compiling, to make sure the
wrong id isn't used with a modded version. So Linux builds from source
are likely to have no gitident, just the version number and timestamp.

I have to patch out timestamps to prevent excessive rebuilds in our
automatic build system, the 2.1.2 patch didn't apply so I'm leaving that
till last.

So you're removing the timestring, &Time=Mar8201714:01:59. If you do
you can put whatever arguments you like on the URL instead, e.g.
&SUSEBuildID=1234
or just
&SUSE
Our script for 'check version' is doing simple string matching. So you
'from_ver=2.1.3&SUSEBuildID=1234'
to give the message 'You are using the latest version of Audacity
released for SUSE' and
'from_ver=2.1.3&SUSEBuildID=1233'
to give the message 'A more recent version of Audacity for SUSE is
available'

In the static LTS type releases like Leap:42 we don't encourage and
disable automatic updates. This is handled by an update repository.
Tumbleweed, the rolling release, announces updates when new snapshots
are released usually once a week. I also maintain an audacity package in
Packman with all the extra codecs like lame, this is linked to the
development package in multimedia:apps with macros that enable the use
of extra codecs. This is where this package will go when I've finished
and then on to Tumbleweed. The 2.1.3 release will go to the next
Leap:42.3 which is currently under development.
Best regards
Dave

Post by James Crook
We can then just update our script on our server wit those strings/messages.

Post by Dave Plater

Post by James Crook
They will therefore appear as 'builds built from source, not by Audacity
team'. IF a maintainer like David wants to work with us on this, he can
provide the query string that openSUSE's build uses when doing
check-version, and we can then add that in to our script and say
'Offical openSUSE 2.1.3 version. Your version is up to date'. The
timestamp will be enough. It doesn't have to have the gitidnet.
Note that we also have enough information to say whether a version is
mac or windows or linux when it is a known build.
--James.

Our %configure macro used in the spec file passes
--host=x86_64-suse-linux-gnu and --build=x86_64-suse-linux-gnu to configure.
cat /etc/os-release
NAME="openSUSE Leap"
VERSION="42.2"
ID=opensuse
ID_LIKE="suse"
VERSION_ID="42.2"
PRETTY_NAME="openSUSE Leap 42.2"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:42.2"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
Currently the Commit Id: field in Build information gives "No revision
identifier was provided" but I use the full git revision code in the
spec file to automatically download the source tarball so I can pass it
to configure.

So, let me check, you get the source zip from github, using the git
revision code, patch the source with your patches, run our
maketarball.sh and then run configure on that?
?from_ver=2.1.3&CommitId=ffe4aa&SUSEPatchID=38adcb
It is up to you if you to what extent you use our 'check for updates'
?from_ver=2.1.3&CommitId=ffe4aa&SUSE
?from_ver=2.1.3&SUSE
We can still tell your patched builds apart from ours.
--James.

[James Crook]

Post by Dave Plater
In the static LTS type releases like Leap:42 we don't encourage and
disable automatic updates. This is handled by an update repository.
Tumbleweed, the rolling release, announces updates when new snapshots
are released usually once a week. I also maintain an audacity package in
Packman with all the extra codecs like lame, this is linked to the
development package in multimedia:apps with macros that enable the use
of extra codecs. This is where this package will go when I've finished
and then on to Tumbleweed. The 2.1.3 release will go to the next
Leap:42.3 which is currently under development.
Best regards
Dave

The 'check for updates' help menu item provides information about
updates, but does not actually do them. You probably don't want the
string to be just:

http://www.audacityteam.org/download/?from_ver=2.1.3

The current message for that on our site is:

"You are using an old or unofficial version of Audacity 2.1.3
This version was never officially released, and is not suitable for
production use."

If you use:
http://www.audacityteam.org/download/?from_ver=2.1.3&SUSE
we can provide a message about whether 2.1.3 is the latest release of
our software, with a link to openSUSE.

or you could sidestep and use:
http://forums.opensuse.org/someurl

--James.

[Dave Plater]

Post by James Crook
The 'check for updates' help menu item provides information about
updates, but does not actually do them. You probably don't want the
http://www.audacityteam.org/download/?from_ver=2.1.3
"You are using an old or unofficial version of Audacity 2.1.3
This version was never officially released, and is not suitable for
production use."

I get this message with the build from git.

Post by James Crook
http://www.audacityteam.org/download/?from_ver=2.1.3&SUSE
we can provide a message about whether 2.1.3 is the latest release of
our software, with a link to openSUSE.
http://forums.opensuse.org/someurl
--James.

I'll have a look around in src/AboutDialog.cpp and work something out.
This is the link to openSUSE one click install:
https://software.opensuse.org/package/audacity?search_term=audacity#pkg-options
I see that it initially displays the Leap:42.1 package, should be the
Leap:42.2 one. I'll file a bug and get it fixed.
This is the link to the Packman package with all the codecs, I see that
it brings up my home:davepl development package as well:
https://pmbs.links2linux.de/search?search_text=audacity
I see that the openSUSE.org link is currently down.

Dave

[Dave Plater]

Post by Dave Plater

Post by James Crook
The 'check for updates' help menu item provides information about
updates, but does not actually do them. You probably don't want the
http://www.audacityteam.org/download/?from_ver=2.1.3
"You are using an old or unofficial version of Audacity 2.1.3
This version was never officially released, and is not suitable for
production use."

I get this message with the build from git.

Post by James Crook
http://www.audacityteam.org/download/?from_ver=2.1.3&SUSE
we can provide a message about whether 2.1.3 is the latest release of
our software, with a link to openSUSE.
http://forums.opensuse.org/someurl
--James.

I'll have a look around in src/AboutDialog.cpp and work something out.
https://software.opensuse.org/package/audacity?search_term=audacity#pkg-options
I see that it initially displays the Leap:42.1 package, should be the
Leap:42.2 one. I'll file a bug and get it fixed.
This is the link to the Packman package with all the codecs, I see that
https://pmbs.links2linux.de/search?search_text=audacity
I see that the openSUSE.org link is currently down.
Dave

To add to this try this interesting link that I use to track down packages:
https://maintainer.zq1.de/?pkg=audacity&type=auto&.submit=Search#audacity

Dave

[James Crook]

Post by Dave Plater

Post by James Crook
The 'check for updates' help menu item provides information about
updates, but does not actually do them. You probably don't want the
http://www.audacityteam.org/download/?from_ver=2.1.3
"You are using an old or unofficial version of Audacity 2.1.3
This version was never officially released, and is not suitable for
production use."

I get this message with the build from git.

Yes. That is intentional. Someone could build Audacity with unpatched
wxWidgets on windows or mac and distribute those binaries, and we don't
want to call that 'the latest official release'. 'This binary was never
officially released by Audacity team, ...' might be better wording for
the message.

To cover all bases we would have to capture a checksum of Audacity and
wxwidgets dlls and pass that as a url arg. Then we can identify unique
binaries. However, that was more work than we wanted to do.

--James.