Bug#997240: lives: FTBFS: htmsocket.c:41:10: fatal error: rpc/rpc.h: No such file or directory

[salsaman]

The line causing the error message can safely be removed as it is
redundant. The correction appears in the most recent stable release, 3.2.0

On Sat, 23 Oct 2021, 16:24 Lucas Nussbaum,  wrote:

> Source: lives
> Version: 3.0.2-1.1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > gcc -DPACKAGE_NAME=\"LiVES\" -DPACKAGE_TARNAME=\"lives\"
> -DPACKAGE_VERSION=\"3.0.2\" -DPACKAGE_STRING=\"LiVES\ 3.0.2\"
> -DPACKAGE_BUGREPORT=\"https://github.com/salsaman/LiVES/issues\;
> -DPACKAGE_URL=\"http://lives-video.com\; -DPACKAGE=\"lives\"
> -DVERSION=\"3.0.2\" -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
> -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1
> -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DHAVE_WCHAR_H=1
> -DHAVE_SYS_PARAM_H=1 -DSTDC_HEADERS=1 -D_ALL_SOURCE=1 -D_DARWIN_C_SOURCE=1
> -D_GNU_SOURCE=1 -D_HPUX_ALT_XOPEN_SOCKET_API=1 -D_NETBSD_SOURCE=1
> -D_OPENBSD_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1
> -D__STDC_WANT_IEC_60559_ATTRIBS_EXT__=1 -D__STDC_WANT_IEC_60559_BFP_EXT__=1
> -D__STDC_WANT_IEC_60559_DFP_EXT__=1 -D__STDC_WANT_IEC_60559_FUNCS_EXT__=1
> -D__STDC_WANT_IEC_60559_TYPES_EXT__=1 -D__STDC_WANT_LIB_EXT2__=1
> -D__STDC_WANT_MATH_SPEC_FUNCS__=1 -D_TANDEM_SOURCE=1 -D__EXTENSIONS__=1
> -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_PTHREAD_PRIO_INHERIT=1
> -DHAVE_PTHREAD=1 -DGETTEXT_PACKAGE=\"lives\"
> -DLOCALEDIR=\"\$\{datarootdir\}/locale\" -DPREFIX=\"/usr\"
> -DLiVES_VERSION=\"3.0.2\" -DHAVE_VISIBILITY=1
> -DHAVE_STDINT_H_WITH_UINTMAX=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1
> -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DINTDIV0_RAISES_SIGFPE=1
> -DHAVE_INTTYPES_H_WITH_UINTMAX=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1
> -DHAVE_UINTMAX_T=1 -DHAVE_INTTYPES_H=1 -DUSE_POSIX_THREADS=1
> -DUSE_POSIX_THREADS_WEAK=1 -DHAVE_PTHREAD_RWLOCK=1
> -DHAVE_PTHREAD_MUTEX_RECURSIVE=1 -DHAVE_BUILTIN_EXPECT=1 -DHAVE_ARGZ_H=1
> -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_UNISTD_H=1
> -DHAVE_SYS_PARAM_H=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1
> -DHAVE_GETGID=1 -DHAVE_GETUID=1 -DHAVE_MEMPCPY=1 -DHAVE_MUNMAP=1
> -DHAVE_STPCPY=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRTOUL=1
> -DHAVE_TSEARCH=1 -DHAVE_ARGZ_COUNT=1 -DHAVE_ARGZ_STRINGIFY=1
> -DHAVE_ARGZ_NEXT=1 -DHAVE___FSETLOCKING=1 -DHAVE_DECL_FEOF_UNLOCKED=1
> -DHAVE_DECL_FGETS_UNLOCKED=1 -DHAVE_ICONV=1 -DICONV_CONST=
> -DHAVE_NL_LOCALE_NAME=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_WCHAR_T=1
> -DHAVE_WINT_T=1 -DHAVE_INTMAX_T=1 -DHAVE_POSIX_PRINTF=1 -DHAVE_STDINT_H=1
> -DHAVE_STDINT_H=1 -DHAVE_STDDEF_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
> -DHAVE_ASPRINTF=1 -DHAVE_FWPRINTF=1 -DHAVE_PUTENV=1 -DHAVE_SETENV=1
> -DHAVE_SETLOCALE=1 -DHAVE_SNPRINTF=1 -DHAVE_WCSLEN=1
> -DHAVE_DECL__SNPRINTF=0 -DHAVE_DECL__SNWPRINTF=0
> -DHAVE_DECL_GETC_UNLOCKED=1 -DHAVE_LANGINFO_CODESET=1 -DHAVE_LC_MESSAGES=1
> -DENABLE_NLS=1 -DHAVE_GETTEXT=1 -DHAVE_DCGETTEXT=1 -DHAVE_LIBDL=1
> -DHAVE_POSIX_MEMALIGN=1 -DHAVE_POSIX_FADVISE=1 -DHAVE_POSIX_FALLOCATE=1
> -DHAVE_SYS_PRCTL_H=1 -DHAVE_LINUX_JOYSTICK_H=1 -DHAVE_JACK_JACK_H=1
> -DHAVE_JACK_TRANSPORT_H=1 -DHAVE_LINUX_VIDEODEV2_H=1 -DHAVE_FREI0R_H=1
> -DHAVE_LIBRAW1394_RAW1394_H=1 -DHAVE_LIBAVC1394_AVC1394_H=1
> -DHAVE_LIBAVC1394_ROM1394_H=1 -I.   -Wdate-time -D_FORTIFY_SOURCE=2 -I..
>  -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong
> -Wformat -Werror=format-security -fcommon -Wall -c -o sendOSC-sendOSC.o
> `test -f 'sendOSC.c' || echo './'`sendOSC.c
> > htmsocket.c:41:10: fatal error: rpc/rpc.h: No such file or directory
> >41 | #include 
> >   |  ^~~
> > compilation terminated.
> > make[3]: *** [Makefile:605: sendOSC-htmsocket.o] Error 1
>
>
> The full build log is available from:
> http://qa-logs.debian.net/2021/10/23/lives_3.0.2-1.1_unstable.log
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> If you reassign this bug to another package, please marking it as
> 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
>
> If you fail to reproduce this, please provide a build log and diff it with
> mine
> so that we can identify if something relevant changed in the meantime.
>
>

Bug#762770: lives cannot find any encoders on startup

[salsaman]

All plugins should be placed inside/lib/lives This is where "make
install" will place them.
If the plugins are installed to a non-standard location then you still need
to edit the config file by hand,
the config file is now in ~/.config/lives/settings

If this is an issue then please feel free to create a feature request
either on github or on sourceforge, and it will be considered for the next
release.

Regards,
Gabriel.


On Tue, 15 Dec 2020 at 18:42, Pander  wrote:

> Perhaps version 3.2.0 which was released in November 2020 solves this.
> See also https://bugs.launchpad.net/ubuntu/+source/lives/+bug/1903465
>
>

Bug#888348: lives: FTBFS with FFmpeg 3.5

[salsaman]

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).

Bug#888348: lives: FTBFS with FFmpeg 3.5

[salsaman]

Please check that you are compiling with the current versions of those
files. There are no instances of CODEC_* any more in those files.

Bug#888348: lives: FTBFS with FFmpeg 3.5

[salsaman]

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

[salsaman]

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.

Bug#810146:

[salsaman]

This bug can be closed with the release of LiVES 2.8.1

Bug#756565:

[salsaman]

This bug can be closed with the release of LiVES 2.8.1

Bug#798043:

[salsaman]

This bug can be closed with the release of LiVES 2.8.1

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

[salsaman]

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.

Bug#798043:

[salsaman]

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/
https://sourceforge.net/p/lives/code/2588/
https://sourceforge.net/p/lives/code/2590/

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

[salsaman]

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 permissions manually, or c) Show a one time pop-up when LiVES
is upgraded asking the user if they want the program to update permissions
for the working directory for them, and if they click Yes, do the update
for them.

Which of the options do you recommend ?

Bug#798043:

[salsaman]

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

[salsaman]

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 in Perl. The only exception is in the .lives config file
where the text  and  must be retained for backwards
compatilbility.

- there were a couple of playback plugins where /tmp was the default for
creating a fifo file inside. Even though the user could overwrite this, the
default has now been changed to create these files in the LiVES working
directory.

- the command "smogrify get_tempdir" has been left alone for backwards
compatibility but is marked as deprecated in the source file. A new
directive "smogrify get_workdir" has been created, this latter version
writes to stdout and other applications may read this with popen().

- a couple of places where LiVES was creating temporary files in /tmp have
been altered to create these in the working directory instead.

I believe that all issues have been addressed. I will continue testing and
examining the code over the next few days to confirm this.


Relevant patches:
https://sourceforge.net/p/lives/code/2570
https://sourceforge.net/p/lives/code/2571
https://sourceforge.net/p/lives/code/2572
https://sourceforge.net/p/lives/code/2573
https://sourceforge.net/p/lives/code/2577

Bug#798043:

[salsaman]

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 be $HOME, and this directory is not created by
the software (it is presumed to exist already.)

The second part of the problem has been resolved. The default permissions
are now used when creating the working directory and any subdrectories of
this.

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

[salsaman]

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
> alternative is to use to use open(2)'s O_CREATE | O_EXCL flags, but this
> will only work if the file does not exist beforehand.
>


Actually I just had a much simpler idea. Since we are only interested in
getting the value, I can alter this function so that the value is written
to stdout instead of to /tmp.

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

[salsaman]

On Tue, Sep 20, 2016 at 1:03 PM, James Cowgill <jcowg...@debian.org> wrote:

> Hi,
>
> [please don't change the subject to 'bug update' - it makes it harder to
> follow threads and is totally pointless]
>
>
I wasnt aware I was changing the subject - it seems like one 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_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 location of $tmpdir at install time so it may be outside
> > $HOME.
>
> I was referring to moving the ~/livestmp directory, not the $tmpdir
> variable which is just an implementation detail. Incidentally since this
> directory is world writable, it's probably vulnerable to the same
> security bugs that /tmp is. Maybe what I said before is wrong and all
> files in $tmpdir are also vulnerable?
>
>

As I mentioned already, the location of this directory is selected by the
user the first time that LiVES is run.
There is nothing forcing it to be ~/livestmp.

The directory being world writeable is a separate bug which will be
addressed there.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798043



> > Regarding the other files:
> >
> > /tmp/lives-symlinks is only used in the Dynebolic bootable disk.
> > Effectively this can be ignored, since it is not used in normal
> operation.
>
> Why does the code still exist then? Can you confirm that it can never
> ever be executed?
>
>



> I have not investigated much, but if it can be executed then it could
> quite easily be used to allow editing of any file in a user's home
> directory.
>
> Attacker: ln -s $HOME_OTHER /tmp/lives-symlinks/$ALL_HANDLES
>
> $linksdir = "/tmp/lives-symlinks/$handle/";
> [some lines]
> $com="/bin/mkdir -p \"$linksdir\"";
> [above command exits without error]
> smog_system("/bin/chmod -R 777 \"$linksdir\"");
>
> [boom]
>
> In this particular case the kernel default security settings will
> probably stop you doing this, but that doesn't mean you can ignore the
> issue. As the kernel reports an error when doing this, smogrify will
> probably fail as well.
>
>

I rechecked and you may be correct in this case. I started reworking this
code now. /tmp will no longer used, instead all the symlinks will be
created in the individual clip directories. In addition, the directory was
set with chmod 777, now it will be created with mode 700.




> > /tmp/.smogrify.* is intended to be used when an external script calls
> > "smogrify get_tempdir ". This may be employed by external scripts
> > to get the working directory location for LiVES. The token  is
> > appended to the end of the filename so this can be considered secure.
> > The LiVES application itself never calls this.
>
> Even using a random  doesn't make it secure. You have to ensure any
> files in /tmp exist and are owned by the user running lives, before
> attempting to read or write to them. Otherwise an attacker could put a
> symlink there and cause the lives user to write to an arbitrary location.
>
>

OK. I will do as you recommend.



> For example, simply grepping the lives source reveals:
> lives-plugins/plugins/playback/video/oggstream.c:
> dummyvar=system("smogrify get_tempdir oggstream");
>
> This allows any user to truncate any file owned by the lives user by
> simply creating a symlink, and waiting for smogrify to be run.
>  ln -s $IMPORTANT_FILE /tmp/.smogrify.oggstream
>
>
Thanks for pointing that out.
The only other place where I know /tmp is used is in
lives-plugins/marcos-encoders. For example in lives_mkv_encoder we have:
temp_dir = tempfile.mkdtemp('', '.lives-', '/tmp/')

However the description of (Python) mkdtemp suggests that this should be
safe:
https://docs.python.org/2/library/tempfile.html

"Creates a temporary directory in the most secure manner possible. There
are no race conditions in the directory’s creation. The directory is
readable, writable, and searchable only by the creating user ID."



>
> > Actually I have a TODO there: allow a (optional) second parameter to
> > override the default directory location (/tmp); so I shall implement
> > this so that scripts can provide an alternative to /tmp if they wish.
> >
> >
> > /tmp/.smogval : this is not used, I believe you are again confused by
> > $tmpdir w

Bug#756565: bug update

[salsaman]

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
location of $tmpdir at install time so it may be outside $HOME.



Regarding the other files:

/tmp/lives-symlinks is only used in the Dynebolic bootable disk.
Effectively this can be ignored, since it is not used in normal operation.


/tmp/.smogrify.* is intended to be used when an external script calls
"smogrify get_tempdir ". This may be employed by external scripts to
get the working directory location for LiVES. The token  is appended
to the end of the filename so this can be considered secure. The LiVES
application itself never calls this.

Actually I have a TODO there: allow a (optional) second parameter to
override the default directory location (/tmp); so I shall implement this
so that scripts can provide an alternative to /tmp if they wish.


/tmp/.smogval : this is not used, I believe you are again confused by
$tmpdir which as noted points to the working directory (e.g. ~/livestmp).
There IS a minor bug where "/tmp/.smogval*" is removed by a cleanup
operation. This code should be removed as it is no longer relevant.


The above changes are trivial and I will update here as soon as they are
done.

Bug#798043: Bug update

[salsaman]

Hi,
first of all, I am the main developer of LiVES. Please cc the address
salsaman+li...@gmail.com to all future bugs related to LiVES. You are also
welcome to report bugs on the mailing list or via the issue tracker (
https://sourceforge.net/p/lives/bugs/).

I will look into the issues that you mention, they should certainly be
considered bugs. The idea with making the working directory world writeable
was to allow collaborative editing, but I agree that this would be better
done via umask.

Regarding the second point (creating ~/livestmp even when the user selects
an alternate) that is certainly a bug if it leaves an empty directory
around. It may be that LiVES needs to create it to write some temporary
files during initialisation, but it ought to delete it afterwards at least,
if it wasn' t there prior to the install.

Thanks for your feedback.


Gabriel.




http://lives-video.com
https://www.openhub.net/accounts/salsaman

Bug#756565: Bug update

[salsaman]

Hi,
first of all, I am the main developer of LiVES. Please cc the address
salsaman+li...@gmail.com to all future bugs related to LiVES.

Secondly, there is incorrect information in this bug report.
>>

You'll see that $curtmpdir is set to /tmp/smogrify, via code such as:

$handle=$ARGV[1];
$curtmpdir="$tmpdir/$handle";

>>

In fact $tmpdir is a bit of a misnomer, it points to the LiVES working
directory, which is created for LiVES at install and chosen by the user,
(or a subdirectory of this). $handle is a random number generated for the
clip. So in this case it would be something like
/home/user/livestmp/34736474/ or
/home/user/livestmp/setname/clips/434637826/


In fact /tmp is not used at all.

If there is a genuine problem here I would be happy to correct it.


Regards,

Gabriel.





http://lives-video.com
https://www.openhub.net/accounts/salsaman

Bug#803839:

[salsaman]

I believe it may be possible to use FF_API_PIX_FMT to determine the older
version complatibility. Somebody please confirm this if possible.

Attached is a (I think correct) patch for the current svn version of LiVES.
With some minor adjustment it should be possible to apply it to older
versions 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 "Salsaman" Finch, 2005 - 2016 */
 
 #ifndef __WEED_COMPAT_H__
 #define __WEED_COMPAT_H__
@@ -595,6 +595,8 @@
 #include 
 #endif
 
+#ifdef FF_API_PIX_FMT
+
 int avi_pix_fmt_to_weed_palette(enum PixelFormat pix_fmt, int *clamped) {
   // clamped may be set to NULL if you are not interested in the value
 
@@ -635,7 +637,7 @@
   case PIX_FMT_YUVJ420P:
 if (clamped) *clamped=WEED_YUV_CLAMPING_UNCLAMPED;
 return WEED_PALETTE_YUV420P;
-
+
   default:
 return WEED_PALETTE_END;
   }
@@ -642,10 +644,7 @@
 }
 
 
-
-
 enum PixelFormat weed_palette_to_avi_pix_fmt(int pal, int *clamped) {
-
   switch (pal) {
   case WEED_PALETTE_RGB24:
   return PIX_FMT_RGB24;
@@ -684,11 +683,100 @@
   default:
 return PIX_FMT_NONE;
   }
+}
 
-  return PIX_FMT_NONE;
+#else
 
+int avi_pix_fmt_to_weed_palette(enum AVPixelFormat pix_fmt, int *clamped) {
+  // clamped may be set to NULL if you are not interested in the value
+
+  switch (pix_fmt) {
+  case AV_PIX_FMT_RGB24:
+return WEED_PALETTE_RGB24;
+  case AV_PIX_FMT_BGR24:
+return WEED_PALETTE_BGR24;
+  case AV_PIX_FMT_RGBA:
+return WEED_PALETTE_RGBA32;
+  case AV_PIX_FMT_BGRA:
+return WEED_PALETTE_BGRA32;
+  case AV_PIX_FMT_ARGB:
+return WEED_PALETTE_ARGB32;
+  case AV_PIX_FMT_YUV444P:
+return WEED_PALETTE_YUV444P;
+  case AV_PIX_FMT_YUV422P:
+return WEED_PALETTE_YUV422P;
+  case AV_PIX_FMT_YUV420P:
+return WEED_PALETTE_YUV420P;
+  case AV_PIX_FMT_YUYV422:
+return WEED_PALETTE_YUYV;
+  case AV_PIX_FMT_UYVY422:
+return WEED_PALETTE_UYVY;
+  case AV_PIX_FMT_UYYVYY411:
+return WEED_PALETTE_YUV411;
+  case AV_PIX_FMT_GRAY8:
+return WEED_PALETTE_A8;
+  case AV_PIX_FMT_MONOWHITE:
+  case AV_PIX_FMT_MONOBLACK:
+return WEED_PALETTE_A1;
+  case AV_PIX_FMT_YUVJ422P:
+if (clamped) *clamped=WEED_YUV_CLAMPING_UNCLAMPED;
+return WEED_PALETTE_YUV422P;
+  case AV_PIX_FMT_YUVJ444P:
+if (clamped) *clamped=WEED_YUV_CLAMPING_UNCLAMPED;
+return WEED_PALETTE_YUV444P;
+  case AV_PIX_FMT_YUVJ420P:
+if (clamped) *clamped=WEED_YUV_CLAMPING_UNCLAMPED;
+return WEED_PALETTE_YUV420P;
+
+  default:
+return WEED_PALETTE_END;
+  }
 }
 
+
+enum AVPixelFormat weed_palette_to_avi_pix_fmt(int pal, int *clamped) {
+  switch (pal) {
+  case WEED_PALETTE_RGB24:
+  return AV_PIX_FMT_RGB24;
+  case WEED_PALETTE_BGR24:
+return AV_PIX_FMT_BGR24;
+  case WEED_PALETTE_RGBA32:
+return AV_PIX_FMT_RGBA;
+  case WEED_PALETTE_BGRA32:
+return AV_PIX_FMT_BGRA;
+  case WEED_PALETTE_ARGB32:
+return AV_PIX_FMT_ARGB;
+  case WEED_PALETTE_YUV444P:
+if (clamped && *clamped==WEED_YUV_CLAMPING_UNCLAMPED)
+  return AV_PIX_FMT_YUVJ444P;
+return AV_PIX_FMT_YUV444P;
+  case WEED_PALETTE_YUV422P:
+if (clamped && *clamped==WEED_YUV_CLAMPING_UNCLAMPED)
+  return AV_PIX_FMT_YUVJ422P;
+return AV_PIX_FMT_YUV422P;
+  case WEED_PALETTE_YUV420P:
+if (clamped && *clamped==WEED_YUV_CLAMPING_UNCLAMPED)
+  return AV_PIX_FMT_YUVJ420P;
+return AV_PIX_FMT_YUV420P;
+  case WEED_PALETTE_YUYV:
+return AV_PIX_FMT_YUYV422;
+  case WEED_PALETTE_UYVY:
+return AV_PIX_FMT_UYVY422;
+  case WEED_PALETTE_YUV411:
+return AV_PIX_FMT_UYYVYY411;
+
+  case WEED_PALETTE_A8:
+return AV_PIX_FMT_GRAY8;
+  case WEED_PALETTE_A1:
+return AV_PIX_FMT_MONOBLACK;
+
+  default:
+return AV_PIX_FMT_NONE;
+  }
+}
+  
+#endif
+  
 #endif // HAVE_AVUTIL
 #endif // HAVE_AVCODEC
 
Index: lives-plugins/plugins/decoders/mkv_decoder.c
===
--- lives-plugins/plugins/decoders/mkv_decoder.c(revision 2406)
+++ lives-plugins/plugins/decoders/mkv_decoder.c(working copy)
@@ -1,5 +1,5 @@
 // LiVES - mkv decoder plugin
-// (c) G. Finch 2011 <salsa...@xs4all.nl,salsa...@gmail.com>
+// (c) G. Finch 2011 - 2016 <salsa...@gmail.com>
 
 /*
  * This file is free software; you can redistribute it and/or
@@ -40,7 +40,7 @@
 #include 
 #include 
 
-const char *plugin_version="LiVES mkv decoder version 1.2";
+const char *plugin_version="LiVES mkv decoder version 1.3";
 
 #ifdef HAVE_AV_CONFIG_H
 #undef HAVE_AV_CONFIG_H
@@ -901,7 +901,7 @@
   out->data = newdata;
   memcpy(out->data+out->size, in->data, in->size);
   out->size += in->size;
-  av_destruct_packet(in);
+  av_packet_

Bug#803839: compile time check

[salsaman]

1) The patch as it stands is completely invalid. Each change needs to have
a version / feature check for backwards compatibility.
2) The change in mkv_decoder.c is not done like that. The correct way is to
#define either av_free_packet or av_destruct_packet in libavhelper.h
. Again a #ifdef 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

[salsaman]

Is there a compile time check for this version (e.g.
LIBAVCODEC_VERSION_MAJOR) or even #ifdef AV_PIX_FMT_RGB24 ?

Bug#762770: lives cannot find any encoders on startup

[salsaman]

If you use a library path other than /usr/lib, (or to be more precise,
$PREFIX/lib) for the plugins you need to do two things:

1) ./configure --libdir=path_to_lib
e.g. ./configure --libdir=/usr/lib/libx86_64-linux-gnu/



Assuming the libweed libs are also in the same directory:

2) Adjust 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

On Thu, Oct 23, 2014 at 11:08 AM, Alessio Treglia ales...@debian.org
wrote:

 On Thu, Sep 25, 2014 at 11:20 AM, Wookey woo...@wookware.org wrote:
  Changing the lib_dir in the ~/.lives file from
  /usr/lib/
  to
  /usr/lib/x86_64-linux-gnu/  (on this machine)
  solves the issue:

 So, essentially you're saying that the very first time you launch
 lives, it creates the config file and then stores file a wrong plugins
 path into it.
 I can't reproduce it now but it sounds likely to me.

 I'm CC'ing the upstream maintainer to get his opinion on this.

 Cheers!

 --
 Alessio Treglia  | www.alessiotreglia.com
 Debian Developer | ales...@debian.org
 Ubuntu Core Developer|  quadris...@ubuntu.com
 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A

Bug#720805: Not a good fix

[salsaman]

I don't think this fix can be correct. On my system (Fedora 17), both
AV_OPT_TYPE_INT and FF_OPT_TYPE_INT are defined as distinct values of the
enum AVOptionType in libavutil/opt.h. Thus adding this #define before
including opt.h causes an error: redeclaration of enumerator
'FF_OPT_TYPE_INT'

The purpose of the #defines in LiVES is to define AV_OPT_TYPE_INT on older
versions of libavutil which did not have AV_OPT_TYPE_INT.

It seems the problem in Sid is due to Debian's use of libavutils from libav
rather than from ffmpeg.

I believe the correct fix may be the following (which I hope 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

Bug#664523: Version of lives to be tested

[salsaman]

I am no the packager, I am the upstream developer. Better to ask
Alessio, Current .debs do not have the patch.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#664523: Bugfix patch

[salsaman]

Yes, as I stated earlier in the comments, you will need the patch
which I indicated.

Salsaman.

main developer, LiVES
http://lives.sourceforge.net



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#664523: Bugfix patch

[salsaman]

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.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#664523: Bugfix patch

[salsaman]

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



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#571549: Fixed in 1.2.1

[salsaman]

This is fixed in 1.2.1



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#555563: Possible fix

[salsaman]

Please apply the following patches and see if it fixes the problem:

http://lives.svn.sourceforge.net/viewvc/lives/trunk/configure.in?r1=316r2=306view=patch
http://lives.svn.sourceforge.net/viewvc/lives/trunk/src/Makefile.am?r1=316r2=151view=patch


Gabriel.
http://lives.sf.net

Bug#546305: closed by Harry Rickards hricka...@l33tmyst.com (Bug#546305: fixed in lives 1.1.2-2)

[salsaman]

On Sun, September 13, 2009 15:14, Harry Rickards wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 09/13/09 14:04, Bastian Blank wrote:
 On Sun, Sep 13, 2009 at 01:20:57PM +0100, Harry Rickards wrote:
 On 09/13/09 12:30, Bastian Blank wrote:
 I don't see a reason for this exclusion. frei0r is built on all
 architecture (except kfreebsd, but temporary unavailable build-deps
 are
 no reason for such an exclusion). Also the changelog does not list
 reasons for that.
 If you trace it down, frei0r isn't avaliable on kfreebsd because it
 depends on libcv-dev which depends on libraw1394-dev, which uses
 components from the Linux kernel. libraw1394-dev is marked as
 Not-For-Us
 on hurd-i386.

 Neither libcv-dev nor libcv1 depends on libraw1394 on my sid system.
 opencv _build-depends_ on it, but does not export the definition any
 further, so this looks suspicious. Please always look down the chain.

 Sorry - I meant Build-Depends. What would you suggest doing - file a bug
 against opencv?

 frei0r isn't little endian safe (that's upstreams advice) so shouldn't
 be depended on in powerpc.

 Where is the RC bug against frei0r? It is built on all architectures,
 but half of them (hppa, mips, powerpc, s390 and sparc) are big-endian.

 I was just given a forwarded post from the frei0r-devel mailing list by
 the upstream author. I'm CC'ing this to thim, and he should be able to
 give you more details.


As far as I know there is no bug report for this. The problem was detected
by developers working on kdenlive/MLT, who forwarded the information to
the frei0r-devel mailing list.

The plugins will work on all architectures, but will produce strange (and
likely unwanted) visual effects on big-endian systems.

Regards,
Gabriel.
http://lives.sourceforge.net





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#543952: lives: Lives crashes at startup on AMD64 (at least mine)

[salsaman]

-get source lives', and rm
 - -rf the debian/ directory. Then download the new debian/ from SVN with
 'svn checkout
 http://svn.debian.org/viewsvn/collab-maint/deb-maint/lives/trunk/debian'.
 You'll
 need to rm -rf the .svn and wrapper/.svn directories. Then, if you're
 running as root run 'dpkg-buildpackage' else run 'dpkg-buildpackage
 - -rsudo'. You can replace sudo with fakeroot or any other
 gain-root-command. Then install with dpkg -i.

 If you still have the problem after that it must be an upstream issue.
 If that's the case, please report the bug against lives on Sourceforge
 at https://sourceforge.net/tracker/?group_id=64341atid=507139. You'll
 probably want to compile with deubgging symbols first, which I think
 (I'm no C developer) you can do by going back to the directory the
 source of lives is in and running ./configure CFLAGS=-ggdb and then make
 and make install.

 I'm CC'ing this to Upstream (Gabriel 'salsaman' Finch) in case he can
 shed any light on the matter.

 - --
 Thanks
 Harry Rickards hricka...@l33tmyst.com

 _,   _,  ,'`.
   `$$' `$$' `.  ,'
$$   $$`'
$$   $$ _,   _
  ,d$$$g$$  ,d$$$b.  $$,d$$$b.`$$' g$b.`$$,d$$b.
 ,$P'  `$$ ,$P' `Y$. $$$'  `$$ $$  '   `$$ $$$' `$$
 $$'$$ $$'   `$$ $$'$$ $$  ,g$$ $$'   $$
 $$ $$ $$g$$ $$ $$ $$ ,$P   $$ $$$$
 $$,$$ $$.   $$,$P $$ $$'   ,$$ $$$$
 `$g. ,$$$ `$$._ _., $$ _,g$P' $$ `$b. ,$$$ $$$$
  `Y$$P'$$. `YP',P'  ,$$. `Y$$P'$$.$$.  ,$$.

 Proud Debian and Ubuntu maintainer of LiVES!
 http://packages.qa.debian.org/l/lives.html
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iJwEAQECAAYFAkqWyhAACgkQ+9DWHFhEn2/7xAP+Jo0i3XZ0z6LOb8lDJ/DNCq0j
 MHOaYRcWFCggS2ZYBooPh/0sDoWoYX0NGLVJJgf2F2Ri+j8UHL8MLiiLU1VUej4R
 XdYxF6QtAaDlv1QgRhaGQqruYk8/QEV2+XsQDUrvWkvFiyvN8lMTAr4rZNj27IIh
 IRSf21xNqaNz4LLkVgY=
 =e3r5
 -END PGP SIGNATURE-


Dependency issue (due to LiVES being compiled with frei0r support but
without frei0r installed at runtime).

A workaround is to delete
/usr/lib/lives/plugins/effects/realtime/weed/frei0r.h

Should be fixed in 1.0.0-5

Gabriel.





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#543952: lives: Lives crashes at startup on AMD64 (at least mine)

[salsaman]

-get source lives', and rm
 - -rf the debian/ directory. Then download the new debian/ from SVN with
 'svn checkout
 http://svn.debian.org/viewsvn/collab-maint/deb-maint/lives/trunk/debian'.
 You'll
 need to rm -rf the .svn and wrapper/.svn directories. Then, if you're
 running as root run 'dpkg-buildpackage' else run 'dpkg-buildpackage
 - -rsudo'. You can replace sudo with fakeroot or any other
 gain-root-command. Then install with dpkg -i.

 If you still have the problem after that it must be an upstream issue.
 If that's the case, please report the bug against lives on Sourceforge
 at https://sourceforge.net/tracker/?group_id=64341atid=507139. You'll
 probably want to compile with deubgging symbols first, which I think
 (I'm no C developer) you can do by going back to the directory the
 source of lives is in and running ./configure CFLAGS=-ggdb and then make
 and make install.

 I'm CC'ing this to Upstream (Gabriel 'salsaman' Finch) in case he can
 shed any light on the matter.

 - --
 Thanks
 Harry Rickards hricka...@l33tmyst.com

 _,   _,  ,'`.
   `$$' `$$' `.  ,'
$$   $$`'
$$   $$ _,   _
  ,d$$$g$$  ,d$$$b.  $$,d$$$b.`$$' g$b.`$$,d$$b.
 ,$P'  `$$ ,$P' `Y$. $$$'  `$$ $$  '   `$$ $$$' `$$
 $$'$$ $$'   `$$ $$'$$ $$  ,g$$ $$'   $$
 $$ $$ $$g$$ $$ $$ $$ ,$P   $$ $$$$
 $$,$$ $$.   $$,$P $$ $$'   ,$$ $$$$
 `$g. ,$$$ `$$._ _., $$ _,g$P' $$ `$b. ,$$$ $$$$
  `Y$$P'$$. `YP',P'  ,$$. `Y$$P'$$.$$.  ,$$.

 Proud Debian and Ubuntu maintainer of LiVES!
 http://packages.qa.debian.org/l/lives.html
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iJwEAQECAAYFAkqWyhAACgkQ+9DWHFhEn2/7xAP+Jo0i3XZ0z6LOb8lDJ/DNCq0j
 MHOaYRcWFCggS2ZYBooPh/0sDoWoYX0NGLVJJgf2F2Ri+j8UHL8MLiiLU1VUej4R
 XdYxF6QtAaDlv1QgRhaGQqruYk8/QEV2+XsQDUrvWkvFiyvN8lMTAr4rZNj27IIh
 IRSf21xNqaNz4LLkVgY=
 =e3r5
 -END PGP SIGNATURE-




Hmm, now actually I take that back. Here I have removed the frei0r plugins
and header file. There is no crash, I just get:

error loading plugin /usr/lib//lives/plugins/effects/realtime/weed/frei0r.so


so it is not just a dependency problem.

In fact I am not able to reproduce this crash at all (ubuntu 9.04, AMD64).

However several people have reported it:

https://sourceforge.net/tracker/?func=detailaid=2824427group_id=64341atid=507139

it appears to affect a seemingly random subset of users.

If anybody can help debugging this it would be greatly appreciated.


As mentioned, a workaround is to remove the file
/usr/lib//lives/plugins/effects/realtime/weed/frei0r.so


Regards,
Gabriel.





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#542831: lintian: Convertor is reported as a spelling mistake with -E

[salsaman]

On Fri, August 21, 2009 19:22, Harry Rickards wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Russ Allbery wrote:
 Harry Rickards hricka...@l33tmyst.com writes:
 Russ Allbery wrote:

 I'm afraid those dictionaries are wrong, at least as dictionaries are
 normally judged.  The word is converter per both Merriam-Webster and
 the Oxford English Dictionary.  The OED specifically lists convertor
 as
 an erroneous spelling.

 Okay. Shall I close the bug?

 Yeah, if you're okay with that answer.

 I'll wait for the reply of Gabriel Finch (the one I cc'ed my previous
 response to) who's the one that pointed out that convertor might be a
 word.

 - --
 Thanks
 Harry Rickards hricka...@l33tmyst.com

 GPG Key Info:
 pub   1024R/58449F6F 2009-06-12
 uid  Harry Rickards (OpenPGP Card)
 hricka...@l33tmyst.com
 sub   1024R/D775CCEE 2009-06-12
 sub   1024R/9394048C 2009-06-12
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

 iJwEAQECAAYFAkqO180ACgkQ+9DWHFhEn28+6QQAwR0A0KeBFuwOP9MQUxLXWPTg
 1Z+sf0itWRkg5q05VQlim8Qh2DNDuzOjOelCCHBWZR4H9c6pjhOyx2mSGaT0ZWa/
 Ahi0RTeSTQjEkELGokUo1A6npcmBb4FT9UEzlQifEJTQ8RqQdEXb6TrqG8lBzBxJ
 MO+PqP2aIcQFtBTdkac=
 =MGK1
 -END PGP SIGNATURE-


I am surprised by this, but I am prepared to accept the authority of the
OED. Will correct the spelling in the LiVES trunk source, and feel free to
close this bug.

Note that in libweed there is a #define WEED_FILTER_IS_CONVERTOR. I think
the best course of action is to leave this as it is, #define a synonym
WEED_FILTER_IS_CONVERTER and mark WEED_FILTER_IS_CONVERTOR as deprecated -
to be removed.

Regards,
Gabriel.

http://lives.sourceforge.net





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#538881: ITP: libweed0 -- Library for inclusion of plugins into LiVES

[salsaman]

On Tue, July 28, 2009 12:14, Harry Rickards wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Christian Marillat wrote:
 Harry Rickards hricka...@l33tmyst.com writes:

 Christian Marillat wrote:
 Harry Rickards hricka...@l33tmyst.com writes:

 [...]

 The diff in this link doesn't provides packages for the shared library
 when my diff does. Then which diff do you think is the best for you ?
 As far as I can tell your diff provides libweed as part of the lives
 package. You also seem to have a binary only libweed package, which
 would mean that lives wouldn't be accepted into the main repo.

 Are you sure ? My diff provides 4 packages.

 ,
 | $ dh_listpackages
 | lives
 | lives-data
 | libweed0
 | libwee-dev
 `

 Christian
 Oh yeah. Sorry that was me being dumb.
 It looks as though lives is in quite capable hands, so I'll let you do
 the packaging work. If you'd like any of the work I've done, it's
 available at http://mentors.debian.net/debian/pool/main/l/lives/ and
 http://l33tmyst.com/weed.tgz

 - --
 Thanks
 Harry Rickards hricka...@l33tmyst.com

 GPG Key Info:
 pub   1024R/58449F6F 2009-06-12
 uid  Harry Rickards (OpenPGP Card)
 hricka...@l33tmyst.com
 sub   1024R/D775CCEE 2009-06-12
 sub   1024R/9394048C 2009-06-12
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

 iJwEAQECAAYFAkpuz4YACgkQ+9DWHFhEn2+qBwP/WifgrMms9YAlitgnDNxWa12m
 4tOwIbEScOCcam/eqflHWpSp6rvfGGnhonXn1f2oTAo6PAdkWMsYd1R5kjBxyaG2
 5h/sKD8tQvW0gFxAkiXZmkvv/t/yCq2kxiuaKkX5rPHjJsSDRugztP+D9XY8TxQ1
 hu+/poLvTgDKXHf+MsY=
 =Dg9I
 -END PGP SIGNATURE-



Look, I don't care who makes the packages, I want them in the official
debian repostiories, not sitting on debian-multimedia.org.

Seems like now we are back to square one.

Thanks a lot guys.


Gabriel.





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#538881: ITP: libweed0 -- Library for inclusion of plugins into LiVES

[salsaman]

On Tue, July 28, 2009 12:14, Harry Rickards wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Christian Marillat wrote:
 Harry Rickards hricka...@l33tmyst.com writes:

 Christian Marillat wrote:
 Harry Rickards hricka...@l33tmyst.com writes:

 [...]

 The diff in this link doesn't provides packages for the shared library
 when my diff does. Then which diff do you think is the best for you ?
 As far as I can tell your diff provides libweed as part of the lives
 package. You also seem to have a binary only libweed package, which
 would mean that lives wouldn't be accepted into the main repo.

 Are you sure ? My diff provides 4 packages.

 ,
 | $ dh_listpackages
 | lives
 | lives-data
 | libweed0
 | libwee-dev
 `

 Christian
 Oh yeah. Sorry that was me being dumb.
 It looks as though lives is in quite capable hands, so I'll let you do
 the packaging work. If you'd like any of the work I've done, it's
 available at http://mentors.debian.net/debian/pool/main/l/lives/ and
 http://l33tmyst.com/weed.tgz



Christian, can we put your packages in the main debain repositories ?


Gabriel.





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#247337: [Fwd: Re: [Fwd: lives_0.9.8.10-1_powerpc.changes REJECTED]]

[salsaman]

Robert,
it appears that your email is no longer functioning. Please update me with
your new email address.

Gabriel.






-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#247337: [Fwd: Re: [Fwd: lives_0.9.8.10-1_powerpc.changes REJECTED]]

[salsaman]

OK. How long does approval normally take ?


Also, you should have checked the file list with me first. Libraries like:

./usr/lib/lives/plugins/playback/video/lives2lives_stream.a

./usr/lib/lives/plugins/playback/video/SDL.a

./usr/lib/lives/plugins/effects/realtime/weed/*.a


are redundant, because these are all dynamically linked at runtime, so
only the .so and .la versions are used.

You may want to bear this in mind for the next release.


Regards,
Gabriel.





On Sat, February 7, 2009 00:40, Robert Millan wrote:
 On Sat, Feb 07, 2009 at 12:00:38AM +0100, salsa...@xs4all.nl wrote:

 LiVES 0.9.9.6 has been released today. This version should be suitable
 for
 inclusion in debian. All requested changes have been made.

 See http://lives.sourceforge.net/index.php?do=downloads for full
 details.


 Please keep me updated with any progress.

 Hi Gabriel,

 Please excuse me for not having notified you, we uploaded a snapshot and
 is currently in ftp-master queue pending approval:

   http://ftp-master.debian.org/new/lives_0.9.9.5+20090126+debian-1.html

 --
 Robert Millan

   The DRM opt-in fallacy: Your data belongs to us. We will decide when
 (and
   how) you may access your data; but nobody's threatening your freedom: we
   still allow you to remove your data and not access it at all.






-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#247337: [Fwd: Re: [Fwd: lives_0.9.8.10-1_powerpc.changes REJECTED]]

[salsaman]

On Wed, January 7, 2009 13:19, Gürkan Sengün wrote:
 hello gabriel

 OK, all of the fixes asked for have now been checked in to CVS.

 Can I now, *finally*, expect a debian package of LiVES !?!?!?!

 there are such packages, just not officially in debian. could you make
 a tarball release of all this stuff of CVS?

 regards,
 guerkan senguen

 Regards,
 Gabriel salsaman,
 http://lives.sourceforge.net




LiVES 0.9.9.6 has been released today. This version should be suitable for
inclusion in debian. All requested changes have been made.

See http://lives.sourceforge.net/index.php?do=downloads for full details.


Please keep me updated with any progress.



Regards,
Gabriel
http://lives.sourceforge.net






--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#247337: [Fwd: Re: [Fwd: lives_0.9.8.10-1_powerpc.changes REJECTED]]

[salsaman]

On Wed, December 17, 2008 22:50, Robert Millan wrote:
 On Tue, Apr 29, 2008 at 04:01:59PM +0200, Gürkan Sengün wrote:
 On Tue, April 29, 2008 09:29, Gürkan Sengün wrote:
 Dear Salsaman,
 
 Could you relicense all of your software parts of lives into
 GNU GPL v3, or 2, or 2.1, whatever you like best?
 
 That'll make inclusion of lives into Debian (and Ubuntu) a lot
 easier.
 
 Thank you,
 Gürkan

 Hi,
 all of the LiVES software is licensed under the GPL v3 or later. The
 only
 exception is weed.h, weed.c, weed-utils.c which will become a library
 under the LGPL v3 or later. If you find any source files which are
 incorrectly licensed, please let me know and I will correct this.

 [...]

 I will take a look at the debian/copyright file and update it as
 necessary.

 Hi,

 Any progress on this?  I'd really like to see an OGG-capable editor in
 Debian,
 and Lives looks like a good option.

 If you need more details, this was the response from FTP team (as posted
 in
 the bug log):

 quote
 Additionally your debian/copyright file is incomplete and misses
 (C)holders/license data. You have to include all such differences.
 Like all of libOSC/*, some of the icons.

 And next, it includes a mixture of GPL/LGPL v2/v2.1 and v3.
 Now you need to check if all v2/v2.1 ones are or any later. If not it
 is undistributable.
 /quote

 RFX.spec is a documentation file which documents a standard. I am happy
 to
 change the license for this to whatever you recommend (what does debian
 recommend for standards ?).

 GPL or LGPL would be fine.

 --
 Robert Millan

   The DRM opt-in fallacy: Your data belongs to us. We will decide when
 (and
   how) you may access your data; but nobody's threatening your freedom: we
   still allow you to remove your data and not access it at all.














OK, all of the fixes asked for have now been checked in to CVS.

Can I now, *finally*, expect a debian package of LiVES !?!?!?!



Regards,
Gabriel salsaman,
http://lives.sourceforge.net





--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#247337: [Fwd: Re: [Fwd: lives_0.9.8.10-1_powerpc.changes REJECTED]]

[salsaman]

On Fri, December 19, 2008 19:28, Robert Millan wrote:
 On Thu, Dec 18, 2008 at 01:14:49AM +0100, salsa...@xs4all.nl wrote:
  quote
  Additionally your debian/copyright file is incomplete and misses
  (C)holders/license data. You have to include all such differences.
  Like all of libOSC/*, some of the icons.
 

 There was some code in colourspace.c which was by another author, it was
 basically minimal code (setting some conversion values in tables). All
 of
 this has now been rewritten from scratch. As far as I know the copyright
 file is up to date. If anybody finds something missing, let me know and
 I
 can add it in.

 Great! Sounds like that would be solved now.

I hope so. Somebody mentioned the icons also last time - I can't believe
anybody would complain, they are 16 x 16 pixel (8 in total) bitmaps used
for play/rewind/stop/pause etc buttons. But I have added the thanks in to
the debian/copyright file now.





  And next, it includes a mixture of GPL/LGPL v2/v2.1 and v3.
  Now you need to check if all v2/v2.1 ones are or any later. If not
 it
  is undistributable.
  /quote
 

 All of the LiVES code is licensed under the GPL v3 or LGPL v3. In fact,
 I
 made the change on the day that the GPL v3 was released, and am proud of
 that fact.

 Hey, you beat me (win32-loader) by just one day! ;-)


I was following the shinanegans with MS and Novell at the time, and was
keen to take a stand against their supposed patent dealings.



 During the transition there may have been one or two files
 which were mistakenly left as GPL v2 or higher. I believe all such files
 have now been updated. If you find any files marked GPL2 or higher,
 please
 let me know and I will update them.

 GPL v2 or higher files can be combined with GPL v3 code, so this is not a
 problem as far as Debian is concerned.  It's only a problem if they're v2
 only without or later.  Would that be the case for any of your files?



Like I said, all files are GPL/LGPL 3 or higher.

The libOSC code which I distribute with LiVES is not written by me, and is
under a BSD license. This is also mentioned in debian/copyright.




  RFX.spec is a documentation file which documents a standard. I am
 happy
  to
  change the license for this to whatever you recommend (what does
 debian
  recommend for standards ?).
 
  GPL or LGPL would be fine.

 OK, I still need to make this one change, I will check it into CVS now.

 Sorry, I was not particularly bright that day.  GPL or LGPL is indeed fine
 for
 Debian, in that it makes the document free (modifiable, etc), but I didn't
 understand what you meant about a license for standards.

 When people write a standard, it's logical they don't want modified
 versions
 to be also considered the same standard unless they previously sanction
 them.

 But sometimes standard drafters (like the RFC) take this too far and
 forbid
 moficication completely, making the document non-free.

 If you wanted to allow modification only in case they give the standard
 another
 name, you could draft a license specifically for this.  That's what the
 Apache
 folks did, but it's really a bad idea.  It breaks GPL compatibility and it
 abuses copyright to do something that really belongs to trademarks.  For
 version 2 of their license, it seems they realized this, and simply said:

 quote
 This License does not grant permission to use the [...] trademarks
 /quote

 GPLv3 has a provision for something similar:

 quote
   Notwithstanding any other provision of this License, for material you
 add to a covered work, you may (if authorized by the copyright holders of
 that material) supplement the terms of this License with terms:

 [...]
 c) Prohibiting misrepresentation of the origin of that material, or
 requiring that modified versions of such material be marked in
 reasonable ways as different from the original version; or

 [...]

 e) Declining to grant rights under trademark law for use of some
 trade names, trademarks, or service marks; or
 /quote

 which you might find useful.  Hope that helps!

 --
 Robert Millan

   The DRM opt-in fallacy: Your data belongs to us. We will decide when
 (and
   how) you may access your data; but nobody's threatening your freedom: we
   still allow you to remove your data and not access it at all.




I am not too bothered about this really. I have now changed the license of
the document to GNU FDL, and the standard itself is now GPL.

(Incidentally, that brings me on to another point, off topic, but I have
always wondered why the FSF don't introduce the GPSL (GNU Public Standards
License). I intend to ask RMS about it the next time I see him.)




Anyway, back to the main point, I hope we can get moving on this soon and
get LiVES into the official debian repositories.

As was mentioned initially, indeed LiVES offers great ogg/theora support
both for encoding and decoding (instant decode is now a feature). In
future I plan to offer enhanced support for other free codecs, for 

Bug#247337: [Fwd: Re: [Fwd: lives_0.9.8.10-1_powerpc.changes REJECTED]]

[salsaman]

On Wed, December 17, 2008 22:50, Robert Millan wrote:
 On Tue, Apr 29, 2008 at 04:01:59PM +0200, Gürkan Sengün wrote:
 On Tue, April 29, 2008 09:29, Gürkan Sengün wrote:
 Dear Salsaman,
 
 Could you relicense all of your software parts of lives into
 GNU GPL v3, or 2, or 2.1, whatever you like best?
 
 That'll make inclusion of lives into Debian (and Ubuntu) a lot
 easier.
 
 Thank you,
 Gürkan

 Hi,
 all of the LiVES software is licensed under the GPL v3 or later. The
 only
 exception is weed.h, weed.c, weed-utils.c which will become a library
 under the LGPL v3 or later. If you find any source files which are
 incorrectly licensed, please let me know and I will correct this.

 [...]

 I will take a look at the debian/copyright file and update it as
 necessary.

 Hi,

 Any progress on this?  I'd really like to see an OGG-capable editor in
 Debian,
 and Lives looks like a good option.

 If you need more details, this was the response from FTP team (as posted
 in
 the bug log):


I would like to know also.


 quote
 Additionally your debian/copyright file is incomplete and misses
 (C)holders/license data. You have to include all such differences.
 Like all of libOSC/*, some of the icons.


There was some code in colourspace.c which was by another author, it was
basically minimal code (setting some conversion values in tables). All of
this has now been rewritten from scratch. As far as I know the copyright
file is up to date. If anybody finds something missing, let me know and I
can add it in.



 And next, it includes a mixture of GPL/LGPL v2/v2.1 and v3.
 Now you need to check if all v2/v2.1 ones are or any later. If not it
 is undistributable.
 /quote


All of the LiVES code is licensed under the GPL v3 or LGPL v3. In fact, I
made the change on the day that the GPL v3 was released, and am proud of
that fact. During the transition there may have been one or two files
which were mistakenly left as GPL v2 or higher. I believe all such files
have now been updated. If you find any files marked GPL2 or higher, please
let me know and I will update them.


 RFX.spec is a documentation file which documents a standard. I am happy
 to
 change the license for this to whatever you recommend (what does debian
 recommend for standards ?).

 GPL or LGPL would be fine.


OK, I still need to make this one change, I will check it into CVS now.

Salsaman.
http://lives.sourceforge.net



 --
 Robert Millan

   The DRM opt-in fallacy: Your data belongs to us. We will decide when
 (and
   how) you may access your data; but nobody's threatening your freedom: we
   still allow you to remove your data and not access it at all.






--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#247337: [Fwd: lives_0.9.8.10-1_powerpc.changes REJECTED]

[salsaman]

On Tue, April 29, 2008 11:55, Gürkan Sengün wrote:
 I still don't understand the necessity to upload Lives in Debian.

 Without mjpegtools you can't encode in mpeg2. Same for transcode or
 mencoder who doesn't exist in Debian even if you add a note saying
 Lives doesn't work, you need to add this package from this site

 Anyone can add it from wherever he wants, or take a Debian package
 and rebuild it according their needs. This is a lot easier when you can
 just say apt-get source PACKAGE, without having to figure where else it
 is (if it's not in an official debian repository).

 Besides, someone can just use lives effects, then reencode the movie
 into whatever format he wants at the end of all the editing.

   the
 first user will certainly don't understand why Lives doesn't work
 because this use will certainly never read the README.Debian.

 There's no README.Debian.

 Christian

 Yours,
 Gürkan




LiVES will run just fine without mjpegtools, transcode and mencoder.

In fact, 3 years ago I made a version which had no non-free dependencies.

For example, the program is able to encode to ogg theora/vorbis without
any of the above dependencies.

If you ship the program without mjpegtools for example, and the user
selects the mjpegtools encoder, they will get an error message informing
them that they need to install mjpegtools to use that particular encoder.
Hence there is no need for a separate README file.

Regards,
Gabriel.
http://lives.sf.net





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#247337: [Fwd: lives_0.9.8.10-1_powerpc.changes REJECTED]

[salsaman]

On Tue, April 29, 2008 11:57, Christian Marillat wrote:
 Gürkan Sengün [EMAIL PROTECTED] writes:

 I still don't understand the necessity to upload Lives in Debian.

 Without mjpegtools you can't encode in mpeg2. Same for transcode or
 mencoder who doesn't exist in Debian even if you add a note saying
 Lives doesn't work, you need to add this package from this site

 Anyone can add it from wherever he wants, or take a Debian package
 and rebuild it according their needs. This is a lot easier when you can
 just say apt-get source PACKAGE, without having to figure where else it
 is (if it's not in an official debian repository).

 Debian isn't Gentoo.

 Besides, someone can just use lives effects, then reencode the movie
 into whatever format he wants at the end of all the editing.

 the
 first user will certainly don't understand why Lives doesn't work
 because this use will certainly never read the README.Debian.

 There's no README.Debian.

 Even better. How user should guess what is missing then ?

 Christian




There is no need to guess, LiVES will inform you if/when you select an
encoder plugin which has missing requirements.

Also, if the user tries to open (import) a file which has no support in
mplayer, they will see an error message on the terminal informing them
that mplayer is possibly missing a library.


Regards,
Gabriel.
http://lives.sf.net





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#247337: LiVES

[salsaman]

There are LiVES .debs now at debian-multimedia.org.

All that is required is for somebody to copy these packages into the 
main debian repositories.


Salsaman.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#247337: LiVES

[salsaman]

LiVES is now at version 0.9.8, and still there is no full-time debian 
maintainer for this package !


How come nobody has picked this up yet ?

Salsaman.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]