Bug#888348: lives: FTBFS with FFmpeg 3.5

Sorry, my bad: I forgot to update the constants in the .h files. I was looking in the .c files by mistake. Also, I think it should be AV_CODEC_ID_* in the headers (although AV_CODEC_* seemed to work too). ___ pkg-multimedia-maintainers mailing list

Bug#888348: lives: FTBFS with FFmpeg 3.5

Please check that you are compiling with the current versions of those files. There are no instances of CODEC_* any more in those files. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org

Bug#888348: lives: FTBFS with FFmpeg 3.5

I believe all the issues noted should be fixed now. You will need to replace the follwoing files: configure.ac libweed/weed-compat.h libweed/weed-compat.pc plugins/decoders/* (the weed-compat changes are unrelated, but you will need to update them to compile the current decoder plugins).

Bug#888348: lives: FTBFS with FFmpeg 3.5

If you have a moment, perhaps you could pull the newly updated files from lives/lives-plugins/plugins/decoders in subversion ( http://svn.code.sf.net/p/lives/code/trunk) and recompile. It should fix the FTBFS. Gabriel. ___ pkg-multimedia-maintainers

Bug#853520: lives: ftbfs with GCC-7

to gtk_alignment_get_type(). As noted this appears to be a gtk+ issue. On Tue, Jan 31, 2017 at 11:33 AM, salsaman <salsaman+li...@gmail.com> wrote: > Ah OK, got it - inlines now need to be explicitly static or declared in > the header. > > > > > On Tue, Jan 31, 2017 at

Bug#853520: lives: ftbfs with GCC-7

Ah OK, got it - inlines now need to be explicitly static or declared in the header. On Tue, Jan 31, 2017 at 8:32 AM, Matthias Klose <d...@debian.org> wrote: > On 31.01.2017 12:04, salsaman wrote: > > The gcc error makes no sense as the function get_time_from_x() is defined >

Bug#853520: lives: ftbfs with GCC-7

The gcc error makes no sense as the function get_time_from_x() is defined (inline) earlier in multitrack.c at line 971. You should report this as a bug in gcc. The warning regarding gtk_alignment_get_type() is internal to gtk+. You should open a bug report there . The other warnings are vaid for

Bug#798043:

This bug can be closed with the release of LiVES 2.8.1 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#810146:

This bug can be closed with the release of LiVES 2.8.1 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#756565:

This bug can be closed with the release of LiVES 2.8.1 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#810146: lives: encoding fails because empty audio wav file beyond some specific length

Thankyou for your detailed investigation Lionel. This issue has now been addressed in version 2.8.1 of LiVES which should be in the debian repositiries shortly. ___ pkg-multimedia-maintainers mailing list

Bug#798043:

3 more patches - implementing the permissions change as discussed and also ensuring that umask is employed correctly throughout. I think these will be the final patches for this issue, assuming there are no bugs found during testing. https://sourceforge.net/p/lives/code/2587/

Bug#798043: lives: creates (and uses) world-writeable directory

James, I was wondering what action should be taken regarding directory/subdirectory permissions for existing users. The options I can think of (from simplest to most complex): a) do nothing, only new users get the benefit. b) add a note in Release Notes informing users how to update the directory

Bug#798043:

Relevant patches: https://sourceforge.net/p/lives/code/2574/ https://sourceforge.net/p/lives/code/2576/ https://sourceforge.net/p/lives/code/2578/ https://sourceforge.net/p/lives/code/2579/ https://sourceforge.net/p/lives/code/2580/ ___

Bug#756565: lives: Numerous insecure temporary files used in smogrify

All issues noted above have been fixed. In addition: - the terminology has been changed throughout to try to be less confusing. The directory is now referred to as the "LiVES working directory" everywhere. For example prefs->tmpdir is now prefs->workdir in the C code, and $tmpdir is now $workdir

Bug#798043:

This has now been fixed. The problem was that the backend (smogrify) needs to communicate some information to the front end (LiVES) at startup, and to do so it was creating ~/livestmp (the default working directory on first time startup) to write some temporary files in. The default is now set to

Bug#756565: lives: Numerous insecure temporary files used in smogrify

On Thu, Sep 22, 2016 at 7:56 PM, James Cowgill wrote: > > Thinking about this some more, there is a slight race condition here if > the user deletes the file after the checks, but before it's written. I > think the best fix would break the smogrify API unfortunately. One >

Bug#756565: lives: Numerous insecure temporary files used in smogrify

ne can only add comments to this bug by sending email and of course I would need to add a topic to the email. Hopefully just replying will leave it alone then > On 20/09/16 15:51, salsaman wrote: > > I would prefer to keep $tmpdir as it is, I dont see any reason to change > > it to $XDG_C

Bug#756565: bug update

I would prefer to keep $tmpdir as it is, I dont see any reason to change it to $XDG_CACHE_HOME as this variable is only used internally to smogrify. Also using /lives would be confusing as there is already a .lives file and lives-dir which are both created in $HOME. Also the user can select the

Bug#803839:

of LiVES. Index: libweed/weed-compat.h === --- libweed/weed-compat.h (revision 2352) +++ libweed/weed-compat.h (working copy) @@ -42,7 +42,7 @@ */ -/* (C) Gabriel "Salsaman" Finch, 2005 - 2012 */ +/* (C) Gabriel

Bug#803839: compile time check

is needed to identify this change. On Tue, Mar 8, 2016 at 11:15 AM, salsaman <salsa...@gmail.com> wrote: > Is there a compile time check for this version (e.g. > LIBAVCODEC_VERSION_MAJOR) or even #ifdef AV_PIX_FMT_RGB24 ? > > > > __

Bug#803839: compile time check

Is there a compile time check for this version (e.g. LIBAVCODEC_VERSION_MAJOR) or even #ifdef AV_PIX_FMT_RGB24 ? ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org

Bug#762770: lives cannot find any encoders on startup

the library paths in libweed/*.pc A warning about the second change is printed at configure time, the first is not documented, but it quite likely should be. Please test and let me know if this fixes the problem for you. http://lives.sourceforge.net https://www.openhub.net/accounts/salsaman

Bug#720805: Not a good fix

will work in all cases): - #ifndef AV_OPT_TYPE_INT + #if FF_API_OLD_AVOPTIONS leaving the lines in the same place as the original. Regards Salsaman. http://lives.sourceforge.net https://www.ohloh.net/accounts/salsaman ___ pkg-multimedia-maintainers mailing

Bug#664523: Version of lives to be tested

I am no the packager, I am the upstream developer. Better to ask Alessio, Current .debs do not have the patch. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org

Bug#664523: Bugfix patch

Yes, as I stated earlier in the comments, you will need the patch which I indicated. Salsaman. main developer, LiVES http://lives.sourceforge.net ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http

Bug#664523: Bugfix patch

Can we try to get 1.6.2 with this patch into testing ? I understand there was a freeze very recently for the next stable release. 1.6.2 with this patch would be much better than the existing 1.6.1 version. ___ pkg-multimedia-maintainers mailing list

Bug#664523: Bugfix patch

http://lives.svn.sourceforge.net/viewvc/lives/trunk/src/startup.c?r1=1446r2=1509 Regards, Salsaman. http://lives.sourceforge.net https://www.ohloh.net/accounts/salsaman ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers

LiVES error

http://qa.debian.org/debcheck.php?dist=unstablepackage=lives Package is optional and has a Depends on libavc1394-0 Incorrect. LiVES *recommends* libavc1394, but will function just fine without it. Please correct this when possible. Regards, Salsaman. http://lives.sourceforge.net https

Re: LiVES 1.3.3 failing to build

On Tue, May 11, 2010 17:27, Harry Rickards wrote: On 11 May 2010 16:22, Harry Rickards ha...@linux.com wrote: Hi, From https://buildd.debian.org/status/package.php?p=lives I can see that armel, hppa and both kfreebsds built 1.3.3-1 fine, whereas on alpha, hurd-i386, i386, ia64, mips,

Re: LiVES 1.3.3 failing to build

On Tue, May 11, 2010 17:27, Harry Rickards wrote: On 11 May 2010 16:22, Harry Rickards ha...@linux.com wrote: Hi, From https://buildd.debian.org/status/package.php?p=lives I can see that armel, hppa and both kfreebsds built 1.3.3-1 fine, whereas on alpha, hurd-i386, i386, ia64, mips,

Re: LiVES 1.3.3 failing to build

On Tue, May 11, 2010 17:58, Harry Rickards wrote: On 11 May 2010 16:53, salsa...@xs4all.nl wrote: On Tue, May 11, 2010 17:27, Harry Rickards wrote: On 11 May 2010 16:22, Harry Rickards ha...@linux.com wrote: Hi, From https://buildd.debian.org/status/package.php?p=lives I can see that

Re: LiVES 1.3.3 failing to build

On Tue, May 11, 2010 18:02, Harry Rickards wrote: On 11 May 2010 17:00, salsa...@xs4all.nl wrote: On Tue, May 11, 2010 17:27, Harry Rickards wrote: On 11 May 2010 16:22, Harry Rickards ha...@linux.com wrote: Hi, From https://buildd.debian.org/status/package.php?p=lives I can see that