Re: Re: Re: Debian 8 on Late 2005 G5, Graphics Issues

[Mathieu Malaterre]

On Mon, Nov 7, 2016 at 11:40 AM, Daniel Cavalli  wrote:
> Hi Peter,
>
> firstly thanks very much for providing the kernel images.
>
> yesterday I installed Jessie on my newly acquired G5 powerpc (GeForce FX
> 5200 Ultra) and experienced problems with nouveau, which I used the
> parameter nouveau.noaccel=1 as a workaround to get a functioning system.
>
> So I have installed both the 3.18 and the 4.5.0-rc2 versions of the kernels
> you provided. Both seemed to boot up ok to the splash screen, but I could go
> no further, as my wireless usb keyboard and mouse no longer worked. they
> worked fine on the 3.16 kernel. any ideas? I have a wired mouse which worked
> fine for 3.18 and 4.5.0 but unfortunately I don't have a wired keyboard to
> test with. This is the first time I've installed a kernel myself so any
> advice you can provide is appreciated.

I have not tried this kernel but are you sure it is using the same
.config file as Debian or is this a `localmodconfig` build one ?

Re: Bug#842513: vlc: immediate crash on launch on powerpc

[Lennart Sorensen]

On Fri, Nov 04, 2016 at 01:33:36PM -0400, Lennart Sorensen wrote:
> And of course I made a typo while copying things into the patch.
> 
> Doing another build test of it now.
> 
> --- vlc-2.2.4.orig/configure.ac   2016-05-31 12:11:07.0 -0400
> +++ vlc-2.2.4/configure.ac2016-11-04 12:22:02.543265439 -0400
> @@ -1422,25 +1422,24 @@
>VLC_SAVE_FLAGS
>AC_CACHE_CHECK([if \$CC groks AltiVec C extensions],
>[ac_cv_c_altivec], [
> -CFLAGS="${CFLAGS} -maltivec"
> +CFLAGS="${CFLAGS} -maltivec -fno-tree-vectorize"
>  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
>  [#include ]], [
>  [vec_ld(0, (unsigned char *)0);]])], [
> -  ac_cv_c_altivec="-maltivec"
> +  ac_cv_c_altivec="-maltivec -fno-tree-vectorize"
>  ], [
>ac_cv_c_altivec="no"
>  ])
>])
> -  VLC_RESTORE_FLAGS
>AS_IF([test "${ac_cv_c_altivec}" != "no"], [
>  CPPFLAGS="${CPPFLAGS} ${ac_cv_c_altivec}"
>  AC_DEFINE(CAN_COMPILE_C_ALTIVEC, 1, [Define to 1 if C AltiVec extensions 
> are available.])
> -VLC_ADD_CFLAGS([libvlccore],[${ac_cv_c_altivec}])
> -ALTIVEC_CFLAGS="$ALTIVEC_FLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
> -VLC_ADD_CFLAGS([deinterlace],[${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}])
> +ALTIVEC_CFLAGS="$ALTIVEC_CFLAGS ${ac_cv_c_altivec} 
> ${ac_cv_c_altivec_abi}"
> +VLC_ADD_CFLAGS([libdeinterlace],[${ac_cv_c_altivec} 
> ${ac_cv_c_altivec_abi}])
>  have_altivec="yes"
>])
>AC_CHECK_HEADERS(altivec.h)
> +  VLC_RESTORE_FLAGS
>  
>VLC_SAVE_FLAGS
>LDFLAGS="${LDFLAGS} -Wl,-framework,vecLib"

That did not quite work, so I had to try the slightly more complicated
patch.

This patch works:

--- vlc-2.2.4.orig/configure.ac 2016-05-31 12:11:07.0 -0400
+++ vlc-2.2.4/configure.ac  2016-11-08 10:28:54.763640362 -0500
@@ -1422,25 +1422,23 @@
   VLC_SAVE_FLAGS
   AC_CACHE_CHECK([if \$CC groks AltiVec C extensions],
   [ac_cv_c_altivec], [
-CFLAGS="${CFLAGS} -maltivec"
+CFLAGS="${CFLAGS} -maltivec -fno-tree-vectorize"
 AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
 [#include ]], [
 [vec_ld(0, (unsigned char *)0);]])], [
-  ac_cv_c_altivec="-maltivec"
+  ac_cv_c_altivec="-maltivec -fno-tree-vectorize"
 ], [
   ac_cv_c_altivec="no"
 ])
   ])
-  VLC_RESTORE_FLAGS
   AS_IF([test "${ac_cv_c_altivec}" != "no"], [
 CPPFLAGS="${CPPFLAGS} ${ac_cv_c_altivec}"
 AC_DEFINE(CAN_COMPILE_C_ALTIVEC, 1, [Define to 1 if C AltiVec extensions 
are available.])
-VLC_ADD_CFLAGS([libvlccore],[${ac_cv_c_altivec}])
-ALTIVEC_CFLAGS="$ALTIVEC_FLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
-VLC_ADD_CFLAGS([deinterlace],[${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}])
+ALTIVEC_CFLAGS="$ALTIVEC_CFLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
 have_altivec="yes"
   ])
   AC_CHECK_HEADERS(altivec.h)
+  VLC_RESTORE_FLAGS
 
   VLC_SAVE_FLAGS
   LDFLAGS="${LDFLAGS} -Wl,-framework,vecLib"
--- vlc-2.2.4.orig/modules/video_filter/Modules.am  2015-02-02 
14:42:29.0 -0500
+++ vlc-2.2.4/modules/video_filter/Modules.am   2016-11-08 10:28:31.391639060 
-0500
@@ -29,6 +29,7 @@
 libdeinterlace_plugin_la_SOURCES += deinterlace/merge_arm.S
 libdeinterlace_plugin_la_CFLAGS += -DCAN_COMPILE_ARM
 endif
+libdeinterlace_plugin_la_CFLAGS += $(ALTIVEC_CFLAGS)
 video_filter_LTLIBRARIES += libdeinterlace_plugin.la
 
 libdynamicoverlay_plugin_la_SOURCES = \

With this patch, only functions inside a CPU feature check for altivec
support has any vector instructions.

And I realized the reason it was broken is that when using -maltivec and
-O4 (which vlc uses), you get -ftree-vectorize automatically enabled
which means gcc starts to automatically generate vector instructions
all over the place, which is not desired in this case.  It rather defeats
the purpose of having a cpu feature check after all.

-- 
Len Sorensen

Re: Release Architectures for Debian 9 'Stretch'

[John Paul Adrian Glaubitz]

On 11/08/2016 10:10 AM, Thadeu Lima de Souza Cascardo wrote:
>> The best thing that could happen right now was a company approaching
>> Debian, emphasizing the importance of the powerpc architecture for
>> their business, and declaring they will hire two Debian Developers who
>> will contribute to the project as part of their job. But let's not
>> hope for a miracle.

Someone could send a mail to Cumulus Networks which are apparently providing
a Linux distribution based on Debian which supports current PowerPC-based
switches like the Broadcom Trident/Trident+/Trident2 [1].

Adrian

> [1] https://cumulusnetworks.com/support/linux-hardware-compatibility-list/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Release Architectures for Debian 9 'Stretch'

[Thadeu Lima de Souza Cascardo]

On Fri, Nov 04, 2016 at 07:16:00PM +0100, Christoph Biedl wrote:
> luigi burdo wrote...
> 
> > Im thinking to start a petition about ... "dont kill debian penguins on 
> > powerpc"
> 
> Don't. The release team folks are not politicians who get convinced by
> a lot of noise. Unless I completely misunderstand their position, the
> only question that matters is: Can we (as the Debian project) be sure
> powerpc will have backing until EOL stretch (somewhen 2020)?
> 
> The right answer is to create trust for this, not whining around.
> 
> The best thing that could happen right now was a company approaching
> Debian, emphasizing the importance of the powerpc architecture for
> their business, and declaring they will hire two Debian Developers who
> will contribute to the project as part of their job. But let's not
> hope for a miracle.
> 
> A remaining idea was was to appeal and ask for a grace peroid. This
> appeal requires substantiation: Several people would have to sign
> this, people who are well-established contributors to the Debian
> project so it is certain they can do the job and their enthusiasm
> will last (I wouldn't expect I would qualify for that). And during
> that grace period, some two or three weeks, we, the powerpc people,
> show significant progress by fixing all the open issues. The fact
> #832931 did not get resolved in due course was one of things that hit
> the reputation quite badly.

I just got a G4 machine last week and did a succesful build of mariadb.
I sent an update to the bug report and will try to do the build on a
porter box.

Cascardo.

> 
> Even if the appeal is unsuccessful on any stage, a clean backlog will
> certainly help to have jessie-LTS for powerpc, and re-entry as well.
> So please start cracking.
> 
> Christoph