-----Original Message-----From: [email protected]: [email protected]: [email protected]: blfs-dev Digest, Vol 1601, Issue 1Date: Wed, 20 May 2020 12:00:01 -0700 Send blfs-dev mailing list submissions to [email protected]
To subscribe or unsubscribe via the World Wide Web, visit http://lists.linuxfromscratch.org/listinfo/blfs-dev or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specificthan "Re: Contents of blfs-dev digest..." Today's Topics: 1. replacing transcode with handbrake (Pierre Labastie) 2. Re: replacing transcode with handbrake (Douglas R. Reno) 3. Re: replacing transcode with handbrake (Bruce Dubbs) ---------------------------------------------------------------------- Message: 1Date: Wed, 20 May 2020 18:28:56 +0200From: Pierre Labastie < [email protected]>To: BLFS Development List < [email protected]>Subject: [blfs-dev] replacing transcode with handbrakeMessage-ID: < [email protected]>Content-Type: text/plain; charset="UTF-8" Transcode is an old, unmaintained, transcoder for video and audio.I've made a patch to allow building it with GCC 10, but I am not surehow to test it. So maybe time to drop it...At this point, I've discussed with D. Reno, who pointed up thatthere is a replacement, whose name is handbrake [1]. I've not tried to build it yet, but it has both a cli and a gui, andseems to be able to do all what transcode was able to do (correct me ifnot). So my proposition is (after some tests maybe) to drop transcode and addhandbrake (building does not seem hard [2], no idea of the SBU's). Thoughts? Pierre [1] https://handbrake.fr/ [2] https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/handbrake ------------------------------ Message: 2Date: Wed, 20 May 2020 11:37:37 -0500From: "Douglas R. Reno" <[email protected]>To: [email protected] Subject: Re: [blfs-dev] replacing transcode with handbrakeMessage-ID: <[email protected]>Content- Type: text/plain; charset=utf-8; format=flowed On 5/20/20 11:28 AM, Pierre Labastie via blfs-dev wrote: > Transcode is an old, unmaintained, transcoder for video and > audio.I've made a patch to allow building it with GCC 10, but I am > not surehow to test it. So maybe time to drop it...At this point, > I've discussed with D. Reno, who pointed up thatthere is a > replacement, whose name is handbrake [1]. > I've not tried to build it yet, but it has both a cli and a gui, > andseems to be able to do all what transcode was able to do (correct > me ifnot). > So my proposition is (after some tests maybe) to drop transcode and > addhandbrake (building does not seem hard [2], no idea of the SBU's). > Thoughts? > Pierre > [1] https://handbrake.fr/ > [2] > https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/handbrake > One additional advantage to using Handbrake is that it can rip BluRays in addition to DVDs. When I was in charge of the streaming aspect of the eSports club in college, we used Handbrake (in my case, on Debian) to convert the .flv files that OBS Studio used to give out to something more standard... like MP4 or AVI. ------------------------------ Message: 3Date: Wed, 20 May 2020 11:43:19 -0500From: Bruce Dubbs < [email protected]>To: [email protected] Subject: Re: [blfs-dev] replacing transcode with handbrakeMessage-ID: < [email protected]>Content-Type: text/plain; charset=utf-8; format=flowed On 5/20/20 11:28 AM, Pierre Labastie via blfs-dev wrote: > Transcode is an old, unmaintained, transcoder for video and > audio.I've made a patch to allow building it with GCC 10, but I am > not surehow to test it. So maybe time to drop it...At this point, > I've discussed with D. Reno, who pointed up thatthere is a > replacement, whose name is handbrake [1]. > I've not tried to build it yet, but it has both a cli and a gui, > andseems to be able to do all what transcode was able to do (correct > me ifnot). > So my proposition is (after some tests maybe) to drop transcode and > addhandbrake (building does not seem hard [2], no idea of the SBU's). > Thoughts? > Pierre > [1] https://handbrake.fr/ > [2] > https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/handbrake If we cam get rid of a package that uses IM6, then I'm all for it. That would only leave emacs where it is optional. -- Bruce ------------------------------ Subject: Digest Footer For what it is worth I have this patch that makes emacs work with IM7. Have been using it for quite a while without ill effects. It is my understanding that at the time I got it it was\supposed to end up in a future version. diff -uNr emacs-26.2.orig/configure.ac emacs-26.2/configure.ac--- emacs-26.2.orig/configure.ac 2019-04-11 21:53:23.000000000 +0200+++ emacs-26.2/configure.ac 2019-05-13 15:16:12.852838315 +0200@@ -2523,9 +2523,16 @@ if test "${with_imagemagick}" != "no"; then ## 6.3.5 is the earliest version known to work; see Bug#17339. ## 6.8.2 makes Emacs crash; see Bug#13867.- ## 7 and later have not been ported to; See Bug#25967.- IMAGEMAGICK_MODULE="Wand >= 6.3.5 Wand != 6.8.2 Wand < 7"- EMACS_CHECK_MODULES([IMAGEMAGICK], [$IMAGEMAGICK_MODULE])+ IMAGEMAGICK7_MODULE="MagickWand >= 7"+ IMAGEMAGICK6_MODULE="Wand >= 6.3.5 Wand != 6.8.2"+ # As we check for ImageMagick 7 then 6 track which version we find+ EMACS_CHECK_MODULES([IMAGEMAGICK], [$IMAGEMAGICK7_MODULE])+ AS_IF([test $HAVE_IMAGEMAGICK = yes],+ [IMAGEMAGICK_MAJOR=7],+ [+ EMACS_CHECK_MODULES( [IMAGEMAGICK], [$IMAGEMAGICK6_MODULE])+ AS_IF([test $HAVE_IMAGEMAGICK = yes], [IMAGEMAGICK_MAJOR=6])+ ]) if test $HAVE_IMAGEMAGICK = yes; then OLD_CFLAGS=$CFLAGS@@ -2545,6 +2552,8 @@ fi if test $HAVE_IMAGEMAGICK = yes; then AC_DEFINE([HAVE_IMAGEMAGICK], 1, [Define to 1 if using ImageMagick.])+ AC_DEFINE_UNQUOTED([IMAGEMAGICK_MAJOR], [$IMAGEMAGICK_MAJOR],+ [ImageMagick major version number (from configure).]) else IMAGEMAGICK_CFLAGS= IMAGEMAGICK_LIBS =@@ -5408,7 +5417,7 @@ Does Emacs use -lrsvg- 2? ${HAVE_RSVG} Does Emacs use cairo? ${HAVE_CAIRO} Does Emacs use -llcms2? ${HAVE_LCMS2}- Does Emacs use imagemagick (version 6)? ${HAVE_IMAGEMAGICK}+ Does Emacs use imagemagick? ${HAVE_IMAGEMAGICK} Does Emacs support sound? ${HAVE_SOUND} Does Emacs use -lgpm? ${HAVE_GPM} Does Emacs use -ldbus? ${HAVE_DBUS}diff -uNr emacs-26.2.orig/src/image.c emacs-26.2/src/image.c--- emacs- 26.2.orig/src/image.c 2019-03-18 12:58:19.000000000 +0100+++ emacs- 26.2/src/image.c 2019-05-13 15:21:35.820273259 +0200@@ -8272,11 +8272,20 @@ /* The GIF library also defines DrawRectangle, but its never used in Emacs. Therefore rename the function so it doesn't collide with ImageMagick. */ #define DrawRectangle DrawRectangleGif- #include <wand/MagickWand.h>++#if IMAGEMAGICK_MAJOR == 6+# include <wand/MagickWand.h>+# include <magick/version.h>+#else+# include <MagickWand/MagickWand.h>+# include <MagickCore/version.h>+/* ImageMagick 7 compatibility definitions */+# define PixelSetMagickColor PixelSetPixelColor+typedef PixelInfo MagickPixelPacket;+#endif /* ImageMagick 6.5.3 through 6.6.5 hid PixelGetMagickColor for some reason. Emacs seems to work fine with the hidden version, so unhide it. */-#include <magick/version.h> #if 0x653 <= MagickLibVersion && MagickLibVersion <= 0x665 extern WandExport void PixelGetMagickColor (const PixelWand *, MagickPixel Packet *);@@ -8814,7 +8823,7 @@ #endif /* HAVE_MAGICKEXPORTIMAGEPIXELS */ { size_t image_height;- MagickRealType color_scale = 65535.0 / QuantumRange;+ MagickRealType color_scale = 65535.0 / (MagickRealType) QuantumRange; #ifdef USE_CAIRO data = xmalloc (width * height * 4); color_scale /= 256; -- =============================== Maurice van der Stee ([email protected])
-- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
