Re: help needed with LibreOffice Java bridge on armhf

[Rene Engelhard]

Hi,

Am 01.11.23 um 20:42 schrieb Rene Engelhard:
(The workaround would be --without-java which I verified to work on my 
rpi4, but this opens a can of worms. Not only disabling some (built-in) 
features like the Report Builder but especially since there is 
Java-based extensions (_all!) which then get into trouble 
dependency-wise/LO will be blocked from migrating to testing maybe...)


I needed to do that now :(. It's live now in sid.

It now also makes natbrailles autopkgtest fail[1] since that one of 
course wants ure-java which is Out-of-sync and probably should be 
decrufted somewhen:


$ rmadison -s unstable ure-java
ure-java   | 4:7.5.9~rc1-1 | unstable   | armhf, ppc64el, s390x
ure-java   | 4:7.6.4~rc1-1 | unstable   | amd64, arm64, armel, i386

Regards,

Rene

Re: Help needed in reproducing FTBFS of eliom on armhf

[Emanuele Rocca]

Hello Stéphane,

On 2023-09-28 03:31, Stéphane Glondu wrote:
> These days, eliom FTBFS on armhf buildds:
> 
>   https://buildd.debian.org/status/package.php?p=eliom
> 
> I've given it back several times; the failure is consistent.
> 
> However, I cannot reproduce it locally nor on a porterbox (abel).

I also cannot reproduce it in a armhf chroot.

> Looking at the log, a command-line flag is missing but I have no idea why.

Right, the successful build passes the following to ocamlfind while the
failed build on the buildd does not:

  -package js_of_ocaml-ppx

Maybe try to figure out how the build system determines which flags to
pass?

Re: Help with testing u-boot!

[gene heskett]

On 12/29/22 05:06, Vagrant Cascadian wrote:

On 2022-12-29, gene heskett wrote:

On 12/28/22 19:17, Diederik de Haas wrote:

On Thursday, 29 December 2022 00:21:05 CET Vagrant Cascadian wrote:

debian stable (2021.01*), testing (2022.04*), unstable (2022.10*)
and experimental (2023.01-rc*)

...

But a bpi m5 makes no attempt to boot it green led remains dim
forever.


Presuming you mean bananapi-m5, it is not enabled yet in the Debian
packages of u-boot...


I can mount it in my reader, a iso-9660 and its not a u-boot, its
grub. So which of the arm64 iso's is u-booter?


None of the debian-installer iso images contain u-boot. They only work
with systems with EFI firmware installed (which, somewhat confusingly,
u-boot could provide in some cases).

U-boot is board-specific, so a single image will almost never support
booting more than a very small number of systems.

Supported debian-installer platforms that have at some point in history
been tested to work are:

   https://d-i.debian.org/daily-images/arm64/daily/u-boot/

There are SD card images you can build, see the
README.concatenatable_images at:

   https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/

You can typically using the firmware.none.img and manually add
u-boot. Which offsets to write to are board-specific, though there are
often common patterns for various board families (e.g. sunxi SoCs mostly
have the same offsets, rockchip SoC mostly use same offsets)...


The bananapi-m5 appears to be amlogic based, and there are a few other
amlogic based boards enabled in Debian's u-boot-amlogic package, but
unfortunately they require quite a few extra hoops to jump through that
make it difficult for Debian to ship images that you can just write to
boot media.

There are hints at fixing part of the problem at
u-boot.git/doc/board/amlogic/libretech-cc.rst:

   Note that Amlogic provides aml_encrypt_gxl as a 32-bit x86 binary with no
   source code. Should you prefer to avoid that, there are open source reverse
   engineered versions available:
   
   1. gxlimg , which comes with a handy

  Makefile that automates the whole process.
   2. meson-tools 
   
   However, these community-developed alternatives are not endorsed by or

   supported by Amlogic.


live well,
   vagrant
You too. I did find out the dfu problem is the robin nano boards, I 
cloned the gitub version 0.11, built and installed it on the bpi5 only 
to get the exact same failure message, finding in an old old klipper 
config that dfu didn't work on robin nano boards but they also have a 
recipe to upload to a nano.  But that build is for the wrong mcu.


but the klipper board files are even older than Marlins so I'm still 
screwed.


Thanks Vagrant.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Help with testing u-boot!

[Vagrant Cascadian]

On 2022-12-29, Diederik de Haas wrote:
> On Thursday, 29 December 2022 00:21:05 CET Vagrant Cascadian wrote:
>> debian stable (2021.01*), testing (2022.04*), unstable (2022.10*)
>> and experimental (2023.01-rc*)
>>
>> # arm64
>> ...
>> rock64-rk3328
>
> I don't recall ever having issues with u-boot on my Rock64's, so for me 
> 2022.04 - 2022.10 surely work. I'll try the experimental version soon.

I have been testing that one, but thanks for the extra testing!


> I generate my own images for Rock64 and that uses 'dd ... seek=' of 
> idbloader.img and u-boot.itb from the u-boot-rockchip package.
> I have been doing that since 2021-03, so it's very likely that I haven't seen 
> an issue since then.

u-boot-rockchip also includes a u-boot-install-rockchip script which
might simplify the process for you. :)


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Help with testing u-boot!

[Vagrant Cascadian]

On 2022-12-29, gene heskett wrote:
> On 12/28/22 19:17, Diederik de Haas wrote:
>> On Thursday, 29 December 2022 00:21:05 CET Vagrant Cascadian wrote:
>>> debian stable (2021.01*), testing (2022.04*), unstable (2022.10*)
>>> and experimental (2023.01-rc*)
...
> But a bpi m5 makes no attempt to boot it green led remains dim
> forever.

Presuming you mean bananapi-m5, it is not enabled yet in the Debian
packages of u-boot...

> I can mount it in my reader, a iso-9660 and its not a u-boot, its
> grub. So which of the arm64 iso's is u-booter?

None of the debian-installer iso images contain u-boot. They only work
with systems with EFI firmware installed (which, somewhat confusingly,
u-boot could provide in some cases).

U-boot is board-specific, so a single image will almost never support
booting more than a very small number of systems.

Supported debian-installer platforms that have at some point in history
been tested to work are:

  https://d-i.debian.org/daily-images/arm64/daily/u-boot/

There are SD card images you can build, see the
README.concatenatable_images at:

  https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/

You can typically using the firmware.none.img and manually add
u-boot. Which offsets to write to are board-specific, though there are
often common patterns for various board families (e.g. sunxi SoCs mostly
have the same offsets, rockchip SoC mostly use same offsets)...


The bananapi-m5 appears to be amlogic based, and there are a few other
amlogic based boards enabled in Debian's u-boot-amlogic package, but
unfortunately they require quite a few extra hoops to jump through that
make it difficult for Debian to ship images that you can just write to
boot media.

There are hints at fixing part of the problem at
u-boot.git/doc/board/amlogic/libretech-cc.rst:

  Note that Amlogic provides aml_encrypt_gxl as a 32-bit x86 binary with no
  source code. Should you prefer to avoid that, there are open source reverse
  engineered versions available:
  
  1. gxlimg , which comes with a handy
 Makefile that automates the whole process.
  2. meson-tools 
  
  However, these community-developed alternatives are not endorsed by or
  supported by Amlogic.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Help with testing u-boot!

[gene heskett]

On 12/28/22 19:17, Diederik de Haas wrote:

On Thursday, 29 December 2022 00:21:05 CET Vagrant Cascadian wrote:

debian stable (2021.01*), testing (2022.04*), unstable (2022.10*)
and experimental (2023.01-rc*)

# arm64
...
rock64-rk3328


I don't recall ever having issues with u-boot on my Rock64's, so for me
2022.04 - 2022.10 surely work. I'll try the experimental version soon.

I generate my own images for Rock64 and that uses 'dd ... seek=' of
idbloader.img and u-boot.itb from the u-boot-rockchip package.
I have been doing that since 2021-03, so it's very likely that I haven't seen
an issue since then.

HTH,
   Diederik


Humm, I thought I'd see if dfu-util-0.11 worked so I just pulled the 
arm64 daily netinstall iso and put it on a u-sd card. But a bpi m5 makes 
no attempt to boot it, green led remains dim forever. I can mount it in 
my reader, a iso-9660 and its not a u-boot, its grub. So which of the 
arm64 iso's is u-booter?


Thanks all.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Help with testing u-boot!

[Reco]

Hi.

On Wed, Dec 28, 2022 at 03:21:05PM -0800, Vagrant Cascadian wrote:
> On 2022-12-22, Vagrant Cascadian wrote:
> > On 2022-08-20, Vagrant Cascadian wrote:
> >> On 2022-08-10, Vagrant Cascadian wrote:
> >>> This bug is just to delay migration to testing while more platforms get
> >>> tested. If you have a relevent board, please consider testing and
> >>> reporting the status:
> >>>
> >>>   https://wiki.debian.org/U-boot/Status
> 
> I have not received many test results for current or even remotely
> recent u-boot platforms in Debian, and u-boot has been blocked from
> migration to testing partly because of this.
> 
> As the bookworm freeze approaches, this is getting to be... worrysome!

That Ordoid N2 board that I had was damaged about year ago.
I have not procured a replacement to it since then.

So I cannot test u-boot on Odroid N2 in the foreseeable future.

Reco

Re: Help with testing u-boot!

[Diederik de Haas]

On Thursday, 29 December 2022 00:21:05 CET Vagrant Cascadian wrote:
> debian stable (2021.01*), testing (2022.04*), unstable (2022.10*)
> and experimental (2023.01-rc*)
>
> # arm64
> ...
> rock64-rk3328

I don't recall ever having issues with u-boot on my Rock64's, so for me 
2022.04 - 2022.10 surely work. I'll try the experimental version soon.

I generate my own images for Rock64 and that uses 'dd ... seek=' of 
idbloader.img and u-boot.itb from the u-boot-rockchip package.
I have been doing that since 2021-03, so it's very likely that I haven't seen 
an issue since then.

HTH,
  Diederik

signature.asc
Description: This is a digitally signed message part.

Re: Help with boost1.74

[Christian Marillat]

On 09 nov. 2021 20:51, Giovanni Mascellani  wrote:

> Dear Debian ARM people,
>
> last boost1.74 version (1.74.0-12) fails to build on armhf[1], and I
> suspect the failure is caused by the switch to GCC 11, because it
> didn't happen in the version before (compiled with GCC 10).
>
>  [1]
>  
> https://buildd.debian.org/status/fetch.php?pkg=boost1.74=armhf=1.74.0-12=1635842472=0
>
> The problem seems to be this:
> ---
> jump_arm_aapcs_elf_gas.S: Assembler messages:
> jump_arm_aapcs_elf_gas.S:57: Error: selected processor does not
> support `vstmia sp,{d8-d15}' in ARM mode
> jump_arm_aapcs_elf_gas.S:68: Error: selected processor does not
> support `vldmia sp,{d8-d15}' in ARM mode
> ---

Maybe related to bug #996419 ?

Christian

Re: Help with boost1.74

[peter green]

On 09/11/2021 19:51, Giovanni Mascellani wrote:

Dear Debian ARM people,

last boost1.74 version (1.74.0-12) fails to build on armhf[1], and I suspect 
the failure is caused by the switch to GCC 11, because it didn't happen in the 
version before (compiled with GCC 10).


IIRC the Debian gcc-11 package takes a different approach to specifying default 
cpu/fpu,
specifying -march=armv7-a+fp rather than seperate march and mfpu options, I 
wonder if
this is having an influence somehow.

Re: Help with an arm64 specific gcc internal error with polymake

[Adrian Bunk]

On Fri, Nov 27, 2020 at 06:52:05AM -0400, David Bremner wrote:
> Wookey  writes:
> 
> > On 2020-11-17 21:19 +, Dominic Hargreaves wrote:
> >> Thanks for your work on this. As of today polymake has been uploaded
> >> to use gcc-9 which doesn't have this problem, so the perl transition
> >> has been unblocked.
> >
> > I don't understand how this works, because Alex was able to reproduce the
> > all the way back to gcc6, and it's been in bugzilla since 2012.
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52830
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91590
> >
> > Still, immediate issue worked around and hopefully the compiler will
> > get fixed one day.
> 
> At the risk of being repetitive, this is only a workaround for the perl
> transition, it does almost nothing for polymake on arm64. The package is
> still RC buggy since it is compiled with a non-default version of
> gcc. I'm still looking at an arch-specific removal for bullseye.

On amdahl it FTBFS for me with gcc-10 10.2.0-16 but built
with 10.2.0-19, so should build if you upload now.

This Debian change to gcc-10 was never in gcc-9,
which explains why that always worked.

> d

cu
Adrian

Re: Help with an arm64 specific gcc internal error with polymake

[David Bremner]

Wookey  writes:

> On 2020-11-17 21:19 +, Dominic Hargreaves wrote:
>> Thanks for your work on this. As of today polymake has been uploaded
>> to use gcc-9 which doesn't have this problem, so the perl transition
>> has been unblocked.
>
> I don't understand how this works, because Alex was able to reproduce the
> all the way back to gcc6, and it's been in bugzilla since 2012.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52830
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91590
>
> Still, immediate issue worked around and hopefully the compiler will
> get fixed one day.

At the risk of being repetitive, this is only a workaround for the perl
transition, it does almost nothing for polymake on arm64. The package is
still RC buggy since it is compiled with a non-default version of
gcc. I'm still looking at an arch-specific removal for bullseye.

d

Re: Help with an arm64 specific gcc internal error with polymake

[Wookey]

On 2020-11-17 21:19 +, Dominic Hargreaves wrote:
> Thanks for your work on this. As of today polymake has been uploaded
> to use gcc-9 which doesn't have this problem, so the perl transition
> has been unblocked.

I don't understand how this works, because Alex was able to reproduce the
all the way back to gcc6, and it's been in bugzilla since 2012.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52830
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91590

Still, immediate issue worked around and hopefully the compiler will
get fixed one day.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: Help with an arm64 specific gcc internal error with polymake

[Wookey]

On 2020-11-17 20:11 -0400, David Bremner wrote:
> Dominic Hargreaves  writes:

> > Thanks for your work on this. As of today polymake has been uploaded
> > to use gcc-9 which doesn't have this problem, so the perl transition
> > has been unblocked.

Good plan.

> I don't forsee having time (or skills) to debug the ICE, so I hope
> someone has a better idea than dropping arm64 as a build arch for
> polymake.

gcc-snapshot works as well so there is something about gcc 10.2.0 that
tickles this bug. Someone more compiler/c++ clueful than me at arm is
bisecting to work out what's going on, so I am hopeful that we will
understand this reasonably soon, and can hopefully just backport a fix
into gcc-10.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: Help with an arm64 specific gcc internal error with polymake

[David Bremner]

Dominic Hargreaves  writes:

> On Sun, Nov 15, 2020 at 01:49:23AM +, Wookey wrote:
>> On 2020-11-14 16:33 +, Dominic Hargreaves wrote:
>> > On Sat, Nov 14, 2020 at 03:08:14PM +, Wookey wrote:
>> 
>> > > I have just tried it, and the file built OK, getting to a resident
>> > > footprint of about 3.5G before completing. 
>> 
>> OK, reading the bug a bit more carefully, I see that you were getting
>> this preprocessed file to build too. But the original .cc barfs. Very
>> odd. The massive/scary c++ involved is way beyond my ken.
>> 
>> I'll see if I can find someone smarter than me to work out what on
>> earth is going on.
>
> Thanks for your work on this. As of today polymake has been uploaded
> to use gcc-9 which doesn't have this problem, so the perl transition
> has been unblocked. The package is however still RC-buggy. I'm copying
> in the package maintainer too.

I don't forsee having time (or skills) to debug the ICE, so I hope
someone has a better idea than dropping arm64 as a build arch for
polymake.

d

Re: Help with an arm64 specific gcc internal error with polymake

[Dominic Hargreaves]

On Sun, Nov 15, 2020 at 01:49:23AM +, Wookey wrote:
> On 2020-11-14 16:33 +, Dominic Hargreaves wrote:
> > On Sat, Nov 14, 2020 at 03:08:14PM +, Wookey wrote:
> 
> > > I have just tried it, and the file built OK, getting to a resident
> > > footprint of about 3.5G before completing. 
> 
> OK, reading the bug a bit more carefully, I see that you were getting
> this preprocessed file to build too. But the original .cc barfs. Very
> odd. The massive/scary c++ involved is way beyond my ken.
> 
> I'll see if I can find someone smarter than me to work out what on
> earth is going on.

Thanks for your work on this. As of today polymake has been uploaded
to use gcc-9 which doesn't have this problem, so the perl transition
has been unblocked. The package is however still RC-buggy. I'm copying
in the package maintainer too.

Cheers
Dominic

Re: Help with an arm64 specific gcc internal error with polymake

[Wookey]

On 2020-11-14 16:33 +, Dominic Hargreaves wrote:
> On Sat, Nov 14, 2020 at 03:08:14PM +, Wookey wrote:

> > I have just tried it, and the file built OK, getting to a resident
> > footprint of about 3.5G before completing. 

OK, reading the bug a bit more carefully, I see that you were getting
this preprocessed file to build too. But the original .cc barfs. Very
odd. The massive/scary c++ involved is way beyond my ken.

I'll see if I can find someone smarter than me to work out what on
earth is going on.

> Thanks! I realised the new source-only policy for bullseye means this
> probably wouldn't unblock the migration (unless the release team made
> an exception) but it at least would give us an idea of how to move
> forward.

Right, and it's not working anyway. I have just reproduced exactly
what you found, but demonstrated that the OOM killer seems very
unlikely to be relevant.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: Help with an arm64 specific gcc internal error with polymake

[Christian Kastner]

On 11/14/20 4:08 PM, Wookey wrote:
> Yes. I have a 64Gb machine. (emag).

I wasn't aware that the Ampere stuff was generally available, and now I
see that through a generous donation, they power our buildds [1].

Do these run an unmodified Debian?

I'd like to run my own arm64 buildd, but basically I only found SBCs so
far, with the NVMe-capable ones having max 4GB RAM, and the Rpi 4 8GB
RAM but no NVMe. I'd like to have at *least* 16GB, and ideally 32GB or more.

[1] https://www.debian.org/News/2020/20200616

Re: Help with an arm64 specific gcc internal error with polymake

[Dominic Hargreaves]

On Sat, Nov 14, 2020 at 03:08:14PM +, Wookey wrote:
> On 2020-11-14 14:30 +, Dominic Hargreaves wrote:
> > On Wed, Nov 11, 2020 at 10:12:19PM +, Dominic Hargreaves wrote:
> > > During the perl 5.32 transition we observed a build failure on arm64 which
> > > is reproducible on the porterbox and at lease three different buidds::
> > > 
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974073
> 
> > Matthias theorized that this could be the OOM killer, which is why
> > it doesn't happen when built sequentially.
> > 
> > Does anyone have access to a higher RAM machine than the buildds
> > and amdahl (11GiB) that could help test this theory (and maybe do a
> > porter upload to unblock the issue for the perl transition?
> 
> Yes. I have a 64Gb machine. (emag).
> 
> I have just tried it, and the file built OK, getting to a resident
> footprint of about 3.5G before completing. 
> 
> I'll try a polymake build/upload, and report back on the bug(s)

Thanks! I realised the new source-only policy for bullseye means this
probably wouldn't unblock the migration (unless the release team made
an exception) but it at least would give us an idea of how to move
forward.

Cheers
Dominic.

Re: Help with an arm64 specific gcc internal error with polymake

[Wookey]

On 2020-11-14 14:30 +, Dominic Hargreaves wrote:
> On Wed, Nov 11, 2020 at 10:12:19PM +, Dominic Hargreaves wrote:
> > During the perl 5.32 transition we observed a build failure on arm64 which
> > is reproducible on the porterbox and at lease three different buidds::
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974073

> Matthias theorized that this could be the OOM killer, which is why
> it doesn't happen when built sequentially.
> 
> Does anyone have access to a higher RAM machine than the buildds
> and amdahl (11GiB) that could help test this theory (and maybe do a
> porter upload to unblock the issue for the perl transition?

Yes. I have a 64Gb machine. (emag).

I have just tried it, and the file built OK, getting to a resident
footprint of about 3.5G before completing. 

I'll try a polymake build/upload, and report back on the bug(s)


Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: Help with an arm64 specific gcc internal error with polymake

[Dominic Hargreaves]

On Wed, Nov 11, 2020 at 10:12:19PM +, Dominic Hargreaves wrote:
> During the perl 5.32 transition we observed a build failure on arm64 which
> is reproducible on the porterbox and at lease three different buidds::
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974073
> 
> However Matthias Klose (and I) tried to isolate the problem using the
> expanded source and that doesn't fail:
> 
> g++ -c -std=c++14 -g -O2 -fPIC -fstack-protector-strong -ftemplate-depth=200 
> -fno-strict-aliasing -fopenmp -Wshadow -Wlogical-op -Wconversion 
> -Wzero-as-null-pointer-constant -Wno-parentheses -Wno-error=unused-function 
> -Wno-stringop-overflow -Wno-array-bounds SparseMatrix-2.ii
> 
> (source file attached).
> 
> Can anyone help try and pin this down?

Matthias theorized that this could be the OOM killer, which is why
it doesn't happen when built sequentially.

Does anyone have access to a higher RAM machine than the buildds
and amdahl (11GiB) that could help test this theory (and maybe do a
porter upload to unblock the issue for the perl transition?

Cheers
Dominic

Re: [Help] Re: Bug#969552: phipack: arm64 autopkgtest failure: ERROR: Illegal state encountered: �

[Andreas Tille]

Control: tags -1 pending

Hi Lennart,

On Tue, Sep 08, 2020 at 07:23:15PM -0400, Lennart Sorensen wrote:
> > I don't have access to an arm64 system at the moment, but a good start
> > might be to fix the compiler warnings, such as the array subscript out
> > of bounds in global.c line 44.  The rest of the warnings appear harmless.
> > 
> > It would appear that GAP_SIZE = 2 is wrong given GAP[] only contains a
> > single character.
> 
> I found the actual problem.  Someone didn't know that there are 3 types
> of char in C.  char, signed char and unsigned char.  char is _only_ for
> use in strings, and never to be used as a numerical value.  This is due
> to the sign of char being implementation specific.  On x86 it is signed,
> on arm it is unsigned.  So any time you want to work with numerical
> values of a char, you must specify if you want signed or unsigned.
> Changing char ch to unsigned char ch, made x86 fail the same way arm64
> did, and making it signed char, makes both pass the test.

A, thanks a lot.  I was not aware of this but it sounds very sensible
and my guess is that lots of code are affected by the same issue.
 
> So here is a patch that appears to solve the problems in the code.

Thanks a lot

   Andreas.

-- 
http://fam-tille.de

Re: [Help] Re: Bug#969552: phipack: arm64 autopkgtest failure: ERROR: Illegal state encountered: �

[Lennart Sorensen]

On Tue, Sep 08, 2020 at 05:35:45PM -0400, Lennart Sorensen wrote:
> On Tue, Sep 08, 2020 at 10:35:26PM +0200, Andreas Tille wrote:
> > Control: tags -1 help
> > 
> > Hi Debian Arm team,
> > 
> > I admit I have no idea how to deal with this except by excluding
> > arm64 from the list of supported architectures which is definitely
> > not my prefered way of action.
> > 
> > Any help would be really appreciated.
> 
> I don't have access to an arm64 system at the moment, but a good start
> might be to fix the compiler warnings, such as the array subscript out
> of bounds in global.c line 44.  The rest of the warnings appear harmless.
> 
> It would appear that GAP_SIZE = 2 is wrong given GAP[] only contains a
> single character.

I found the actual problem.  Someone didn't know that there are 3 types
of char in C.  char, signed char and unsigned char.  char is _only_ for
use in strings, and never to be used as a numerical value.  This is due
to the sign of char being implementation specific.  On x86 it is signed,
on arm it is unsigned.  So any time you want to work with numerical
values of a char, you must specify if you want signed or unsigned.
Changing char ch to unsigned char ch, made x86 fail the same way arm64
did, and making it signed char, makes both pass the test.

So here is a patch that appears to solve the problems in the code.

-- 
Len Sorensen
diff -ruN phipack-0.0.20160614/src/fasta.c phipack-0.0.20160614.arm64/src/fasta.c
--- phipack-0.0.20160614/src/fasta.c	2016-06-14 00:18:29.0 -0400
+++ phipack-0.0.20160614.arm64/src/fasta.c	2020-09-08 19:08:06.672390326 -0400
@@ -36,7 +36,7 @@
 void read_sequence_name(FILE *in_file,char *name, int capacity)
 {
   int i=0;
-  char ch='\0';
+  signed char ch='\0';
 
   ch=fgetc(in_file);
   if(ch != '>')
@@ -97,7 +97,7 @@
 {
   int bases_read=0;
   int new_limit;
-  char ch;
+  signed char ch;
   char s[250];
   
   ch=fgetc(in_file);
@@ -175,7 +175,7 @@
   int *seq_counter;
   int i;
  
-  char ch;
+  signed char ch;
 
   int cur_seqs;
   int num_seqs=1,new_num;
diff -ruN phipack-0.0.20160614/src/global.c phipack-0.0.20160614.arm64/src/global.c
--- phipack-0.0.20160614/src/global.c	2016-06-13 22:33:15.0 -0400
+++ phipack-0.0.20160614.arm64/src/global.c	2020-09-08 18:04:48.956444973 -0400
@@ -34,7 +34,7 @@
 const int AA_AMBIG_SIZE =2;
 
 const char GAP[] = {'-'};
-const int GAP_SIZE=2;
+const int GAP_SIZE=1;
 
 cbool memberOf(const char *set, const int num, char ch)
 {
@@ -79,10 +79,10 @@
   switch(alignKind)
 {
 case DNA:
-  return (memberOf(DNA_MISSING,DNA_MISSING_SIZE,ch) || memberOf(DNA_AMBIG,DNA_AMBIG_SIZE,ch));
+  return (memberOf(DNA_MISSING,DNA_MISSING_SIZE,ch) || memberOf(DNA_AMBIG,DNA_AMBIG_SIZE,ch)) ? TRUE : FALSE;
   break;
 case AA:
-  return (memberOf(AA_MISSING,AA_MISSING_SIZE,ch) || memberOf(AA_AMBIG,AA_AMBIG_SIZE,ch));
+  return (memberOf(AA_MISSING,AA_MISSING_SIZE,ch) || memberOf(AA_AMBIG,AA_AMBIG_SIZE,ch)) ? TRUE : FALSE;
   break;
 case OTHER:
   if(ch == GLOBAL_MISSING)
diff -ruN phipack-0.0.20160614/src/main.c phipack-0.0.20160614.arm64/src/main.c
--- phipack-0.0.20160614/src/main.c	2016-06-14 00:18:17.0 -0400
+++ phipack-0.0.20160614.arm64/src/main.c	2020-09-08 19:17:18.230153542 -0400
@@ -71,7 +71,8 @@
 
 void get_params(int argc, char**argv, options *opt) 
 { 
-  char *cur,ch,nextch;
+  char *cur;
+  signed char ch,nextch;
   char temp[MAX_SIZE+1];
   int i;
   cbool inFileFound=FALSE;
diff -ruN phipack-0.0.20160614/src/mem.c phipack-0.0.20160614.arm64/src/mem.c
--- phipack-0.0.20160614/src/mem.c	2016-06-13 22:33:15.0 -0400
+++ phipack-0.0.20160614.arm64/src/mem.c	2020-09-08 19:12:52.415278666 -0400
@@ -96,7 +96,7 @@
 
 char ffclose(FILE *handle)
 {
-  char f;
+  signed char f;
   char s[MAX_SIZE+1];
 
   f=fclose(handle);
diff -ruN phipack-0.0.20160614/src/misc.c phipack-0.0.20160614.arm64/src/misc.c
--- phipack-0.0.20160614/src/misc.c	2016-06-13 22:33:15.0 -0400
+++ phipack-0.0.20160614.arm64/src/misc.c	2020-09-08 19:08:28.352322441 -0400
@@ -46,7 +46,7 @@
 
 char skip_all_space(FILE *in_file)
 {
-  char ch;
+  signed char ch;
   
   ch=fgetc(in_file);
   while((ch != EOF) && isspace(ch))
@@ -61,7 +61,7 @@
 
 char skip_newlines(FILE *in_file)
 {
-  char ch;
+  signed char ch;
   
   ch=fgetc(in_file);
   while((ch != EOF) && (ch == '\n'))
@@ -76,7 +76,7 @@
 
 char skip_non_newline(FILE *in_file)
 {
-  char ch;
+  signed char ch;
   
   ch=fgetc(in_file);
   while((ch != EOF) && (ch != '\n'))
@@ -90,7 +90,7 @@
 
 char skip_non_newline_space(FILE *in_file)
 {
-  char ch;
+  signed char ch;
   
   ch=fgetc(in_file);
   while((ch != EOF) && (ch != '\n') && isspace(ch))
diff -ruN phipack-0.0.20160614/src/phylip.c phipack-0.0.20160614.arm64/src/phylip.c
--- phipack-0.0.20160614/src/phylip.c	2016-06-14 00:18:17.0 -0400
+++ phipack-0.0.20160614.arm64/src/phylip.c	2020-09-08 19:10:06.483985652 -0400
@@ -30,7 +30,7 @@
 void read_strict_name(FILE 

Re: [Help] Re: Bug#969552: phipack: arm64 autopkgtest failure: ERROR: Illegal state encountered: �

[Lennart Sorensen]

On Tue, Sep 08, 2020 at 10:35:26PM +0200, Andreas Tille wrote:
> Control: tags -1 help
> 
> Hi Debian Arm team,
> 
> I admit I have no idea how to deal with this except by excluding
> arm64 from the list of supported architectures which is definitely
> not my prefered way of action.
> 
> Any help would be really appreciated.

I don't have access to an arm64 system at the moment, but a good start
might be to fix the compiler warnings, such as the array subscript out
of bounds in global.c line 44.  The rest of the warnings appear harmless.

It would appear that GAP_SIZE = 2 is wrong given GAP[] only contains a
single character.

-- 
Len Sorensen

Re: help

[RobJE Debian ARM]

On 16-02-2020 08:41, Martin Michlmayr wrote:
> * Loic  [2020-02-16 01:47]:
>> I have try to install Debian on my QNAP TS-221 but im block on the
>> Installer.
>> The installation failed when  it's time to download packages.
> 
> Can you open another SSH connection, open a shell and then look at
> /var/log/syslog to see what's going on.

How much RAM does the TS-221 have. When its 1GB this could be the cause
of the issues. There is a known issue with devices that have more than
768M of RAM. See [1]

[1] 

GRTNX,
RobJE

Re: help

[Martin Michlmayr]

* Loic  [2020-02-16 01:47]:
> I have try to install Debian on my QNAP TS-221 but im block on the
> Installer.
> The installation failed when  it's time to download packages.

Can you open another SSH connection, open a shell and then look at
/var/log/syslog to see what's going on.

-- 
Martin Michlmayr
https://www.cyrius.com/

Re: help with racket build failure

[peter green]

my first suspicions when a debugger can't give a useful backtrace are stack 
corruption or a call down a bogus function pointer.

Unfortunately such problems can be a nightmare to debug, I have often resorted to 
debugging with printf statements in the past. Recently "reverse debugging" 
tools have appeared that in principle should be able to help with this sort of thing, but 
I haven't found any free ones for arm linux.

On 13/01/2020 11:36, David Bremner wrote:

Dear Arm experts;

Any help with

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948789

would be appreciated.

I can replicate the crash on harris, and

cd $HOME/racket-7.5+dfsg1/build  && \
gdb --args ./racketcgc -cu \
$HOME/racket-7.5+dfsg1/src/racket/src/compile-startup.rkt cstartup.inc \
cstartup.zo $HOME/racket-7.5+dfsg1/src/racket/src/startup.inc \
$HOME/racket-7.5+dfsg1/src/racket/src/schvers.h

should get you to the segfault in gdb. The backtrace doesn't make much
sense to me, lots of talk about

   

It's entirely possible racket is doing something odd with signals; I
remember something like using SEGFAULTS in gc.

d

Re: Help needed for small assembler script for the iraf package

[Ian Campbell]

On Mon, 2018-01-01 at 15:20 +0100, Ole Streicher wrote:
> However, I have no idea how to write the same for the 64-bit platform
> arm64 (the code in the repo does not work). Maybe someone could help
> me here? Preferably under the IRAF license [3], so that it can be
> included upstream later.

My arm ASM is a bit rusty but doesn't this first instruction:
stp x29, x30, [sp, -32]!
cause sp to be updated (due to the "!")? That leaves the current stack
frame unbalanced since nothing undoes the push before the branch to
__sigsetjmp which cannot itself know to undo that change, so presumably
when __sigsetjmp (or whatever comes next) tries to return over this
stack frame explodes.

It looks like the intention is to preserve x29 in order to use it as a
scratch register, perhaps just use one of the caller saved registers
instead? (infocentre.arm.com seems to be down so I can't refresh my
memory which registers that would be).

Compared to the armhf version it seems to be making a lot of use of
spilling things to the stack slots created by moving sp, and seems to
do awful lot of pointless looking shuffling (although I've not fully
traced through to try and figure out what it thinks it is doing). Does
a more direct translation of the armhf code work, something like
(uncompiled/untested):

str xzr, [x1]  @ *status = 0
str x1, [x0]   @ buf[0] = status
add x0, x0, #8 @ [1] --> 1st arg for sigsetjmp
mov x1, xzr@ 0   --> 2nd arg for sigsetjmp
b   __sigsetjmp@ call sigsetjmp

Apart from changing the register names the main difference from armhf
is the use of xzr instead of loading 0 into r2 and the array step being
8 instead of 4. I also dropped the explicit 0 offsets on the stores,
not sure if that might be possible on the armhf side too -- perhaps the
eventual instruction encoding is the same either way.

I hardly feel like it deserves my copyright, but for formalities sake
please feel free to take the above snippet under an IRAF license.

Ian.

Re: Help needed for small assembler script for the iraf package

[Ole Streicher]

Hi Ian,

thank you very much! I already got an off-list answer from Peter Green
which seems to work well (at least, it passes my tests), and I uploaded
a version that supports all arm platforms now. The code is:

.file   "zsvjmp.s"
.arch armv8-a
.text
.global zsvjmp_
.type   zsvjmp_, %function

zsvjmp_:
str xzr, [x1]   // *status = 0;
str x1, [x0], 8 // ((long **)buf)[0] = status
// also post-increment x0 by 8: 1st arg for sigsetjmp
mov w1, 0   // 0 --> 2nd arg for sigsetjmp
b  __sigsetjmp  // call sigsetjmp

(Using @ as comment delimiter did not work, so I switched to //)

Best regards

Ole

On 02.01.2018 11:06, Ian Campbell wrote:
> On Mon, 2018-01-01 at 15:20 +0100, Ole Streicher wrote:
>> However, I have no idea how to write the same for the 64-bit platform
>> arm64 (the code in the repo does not work). Maybe someone could help
>> me here? Preferably under the IRAF license [3], so that it can be
>> included upstream later.
> 
> My arm ASM is a bit rusty but doesn't this first instruction:
>   stp x29, x30, [sp, -32]!
> cause sp to be updated (due to the "!")? That leaves the current stack
> frame unbalanced since nothing undoes the push before the branch to
> __sigsetjmp which cannot itself know to undo that change, so presumably
> when __sigsetjmp (or whatever comes next) tries to return over this
> stack frame explodes.
> 
> It looks like the intention is to preserve x29 in order to use it as a
> scratch register, perhaps just use one of the caller saved registers
> instead? (infocentre.arm.com seems to be down so I can't refresh my
> memory which registers that would be).
> 
> Compared to the armhf version it seems to be making a lot of use of
> spilling things to the stack slots created by moving sp, and seems to
> do awful lot of pointless looking shuffling (although I've not fully
> traced through to try and figure out what it thinks it is doing). Does
> a more direct translation of the armhf code work, something like
> (uncompiled/untested):
> 
>   str xzr, [x1]  @ *status = 0
>   str x1, [x0]   @ buf[0] = status
>   add x0, x0, #8 @ [1] --> 1st arg for sigsetjmp
>   mov x1, xzr@ 0   --> 2nd arg for sigsetjmp
>   b   __sigsetjmp@ call sigsetjmp
> 
> Apart from changing the register names the main difference from armhf
> is the use of xzr instead of loading 0 into r2 and the array step being
> 8 instead of 4. I also dropped the explicit 0 offsets on the stores,
> not sure if that might be possible on the armhf side too -- perhaps the
> eventual instruction encoding is the same either way.
> 
> I hardly feel like it deserves my copyright, but for formalities sake
> please feel free to take the above snippet under an IRAF license.
> 
> Ian.
> 

Re: Help need with build failure of ceph 10.2.5-2 on armel

[Wookey]

On 2016-12-26 22:52 +0100, Gaudenz Steinlin wrote:
> 
> Hi
> 
> The build of the most recent version of ceph fails on armel[1]. As far
> as I understand the log, the first failure (a bit above the end of the
> log) is because armel does not support NEON (-mfpu=neon) despite the
> configure check for this succeeding.
> 
> The autotools based build system uses the following check:
> AX_CHECK_COMPILE_FLAG(-mfpu=neon, ax_cv_support_neon_ext=yes, [])
> 
> Is it correct that for armel NEON has to be disabled or this there a way
> to support NEON instructions on armel?

You cannot assume neon is present on armel hardware, and more
significantly its use is not supported by the ABI. I presume the
check is testing the build machine, which is not relevant in this
case. (The same machines build armel and armhf, IIRC and are
relatively modern, so at least some of them have neon available).

Neon must be disabled on armel. If a piece of software cannot do this, and
requires neon unconditionally then it is not suitable for armel.

> And how could I fix the above test to correctly disable NEON for
> armel.

The check for neon is 'correct' in the narrow sense that it determines
whether the installed compiler can run with this flag set. This should
fail the same way it does later when the build is tried - I don't know
why it isn't. Explicitly checking for the combination of '-mfpu-neon
-mfloat-abi=softp' should have the desired effect (give an error at
test time so it doesn't try to build the extra plugin). It's not clear
why this is not already the effective test.

Patching the build to simply not use -mfpu=neon (nor check for it)
will result in a non-neon build on armel as the armel gcc defaults are
correct.

Note that neon may not be present on armhf machines either, so
building with an alternate fallback code path (run-time determined)
there is correct, but you'll generally get away with it, as most
machines do in fact have this unit. We probably have a lot of software
not dealing with this properly.

> AFAICS the build failure appears if a source file uses
> "#include ".
> 
> AFAIU the build tries to build a plugin with NEON instructions to be
> used depending on runtime detection.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Re: Help need with build failure of ceph 10.2.5-2 on armel

[peter green]

On 26/12/16 21:52, Gaudenz Steinlin wrote:

AFAICS the build failure appears if a source file uses
"#include".

AFAIU the build tries to build a plugin with NEON instructions to be
used depending on runtime detection.
   
You need to add "-mfloat-abi=softfp" to the compilation of the 
neon-using plugin on armel.


This flag must only be used on armel (not on armhf) and must only be 
used for code that is gaurded behind appropriate runtime detection.

Re: Help with conky/1.10.0-1 armel-only FTBFS

[Edmund Grimley Evans]

 conky/1.10.0-1 has been failing on armel [1], both on the buildds and
 on the abel.d.o porterbox, with errors that aren't seen on armhf or
 arm64. Tail of build log below.

This seems to be related:

https://lists.debian.org/debian-arm/2013/12/msg0.html

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938

It looks as though someone would have to do some work on libstdc++.


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cahdciuc_fd0e2tvfmayykdhnejydn8dne0wuhipqsl2_v0y...@mail.gmail.com

Re: Help with conky/1.10.0-1 armel-only FTBFS

[Vincent Cheng]

On Thu, Jul 2, 2015 at 3:09 AM, Edmund Grimley Evans
edmund.grimley.ev...@gmail.com wrote:
 conky/1.10.0-1 has been failing on armel [1], both on the buildds and
 on the abel.d.o porterbox, with errors that aren't seen on armhf or
 arm64. Tail of build log below.

 This seems to be related:

 https://lists.debian.org/debian-arm/2013/12/msg0.html

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938

 It looks as though someone would have to do some work on libstdc++.

Thanks for the links! I suppose that's reason enough to file an
armel-only RM bug for conky, since it doesn't look like this'll be
fixed anytime soon.

Regards,
Vincent


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caczd_tblndqyfjxd0vngn2qcnpfp4x918k4gq-1xecgbwjx...@mail.gmail.com

Re: help? efivar 0.20-3 fails to build on arm64

[Blibbet]

 Sounds good, thanks.

 OVMF/AAVMF is unfortunately non-free due to the FAT driver license.
 How are RedHat, Linaro etc dealing with that issue?

The UEFI spec requires FAT for the ESP (EFI System Partition). Apple (an
OEM and an OSV) ignores this and uses HFS+ for it's ESP. A Linux OEM
could also choose to ignore FAT and use their own FS for their ESP.

Having a FS that has some security would really be an improvement over
storing firmware images on FAT, IMO.

I thought I'd seen some Linaro slides on UEFI that mentioned Ext2 or
Ext4 support, but can't recall the URL to those slides, sorry. If anyone
finds more info about Linaro (as well as non-ARM-based Linux OEMs) w/r/t
using Ext4 for ESP, please speak up.

OS upgrade issues will be painful when each OEM/OSV includes a different
FS for their ESP. Windows' installer won't recognize Ext4, nor will most
UEFI BIOS implementations, the Linux OEM would need to add it. Similar
issues if installing onto Apple hardware, except HFS+. Read the response
from Apple mid-page, about technical issues:
http://sourceforge.net/p/edk2/mailman/edk2-devel/thread/e9345f56-5607-48df-ac04-60a732e56...@apple.com/

 We had a really interesting discussion about hardware/firmware testing
 on the debian-derivatives list recently, folks interested in that sort
 of stuff might be interested in looking at these links:

 http://biosbits.org/
 https://launchpad.net/fwts
 https://github.com/chipsec/chipsec
 https://github.com/01org/luv-yocto

In addition to Intel bits, Linaro is porting the above 4 URLs to AArch64
(but not AArch32), you can see some Linaro/Intel discusson on the LUV
mailing list:
https://wiki.linaro.org/LEG/Engineering/luvOS
eg:
https://lists.01.org/pipermail/luv/2015-June/000534.html

I'm not clear as to the efivar problem that started the thread, and what
tool(s) you need to help.

Do you have a UEFI Shell for your ARM system? There are a few commands
there to get this data, from UEFI space, if that helps.

There is the linux-efi mailing list, perhaps that'd be helpful? I'm not
100% of what is on- and off-topic on that list.
http://vger.kernel.org/vger-lists.html#linux-efi

There is the Linaro-uefi mailing list, if this problem can be replicated
on their builds.
https://lists.linaro.org/mailman/listinfo/linaro-uefi

Thanks,
Lee
RSS: http://firmwaresecurity.com/feed/


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/558d6c9b.5070...@gmail.com

Re: help? efivar 0.20-3 fails to build on arm64

[Peter Jones]

On Fri, Jun 26, 2015 at 11:46:38AM +0800, Paul Wise wrote:
 On Thu, 2015-06-25 at 11:05 -0400, Peter Jones wrote:
 
  The thing is, *all* the library does is provide a C API for interactions
  with firmware.  So that's really what make test exercises, which is
  why a) it's more useful for did my changes break anything during
  development than anything else, b) it just shouldn't be run in a normal
  package build, and c) it trips up on firmware interaction a lot when the
  firmware isn't very mature.
 
 The best way to avoid b) is to rename it to something other than test
 or check since Debian and probably other distros automatically run
 those make targets.
 
 Some possible alternative options:
 
 make developer-tests
 make maybe-break-my-system-please ;)
 

*ahem*,
https://github.com/rhinstaller/efivar/commit/510b861012c111a362aa4c3da6ba408f2d78aaca

   It might also be interesting for edk2 (ovmf/qemu-efi) to run efivar to
   test themselves.
  
  Yeah, that's definitely a good idea.  My plan for make test has been...
 
 Sounds good, thanks.
 
 OVMF/AAVMF is unfortunately non-free due to the FAT driver license.
 How are RedHat, Linaro etc dealing with that issue?

By not distributing it in Fedora, so far.  We've been looking at
options, and it's worth noting that there *is* a Free-as-in-Freedom FAT
driver ( https://github.com/pbatard/efifs ), but it's derived from grub
code that's GPLv3, and that makes for some interesting legal questions
as well since in at least some of the ovmf/aavmf builds we want Secure
Boot enabled, and absent a whole lot of work that means linking openssl
in.  I'm not even going to get in to thinking about which work is
derivative of which between linking those three trees together.

-- 
Peter


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150626210128.ga9...@redhat.com

Re: help? efivar 0.20-3 fails to build on arm64

[Peter Jones]

On Fri, Jun 26, 2015 at 08:15:39AM -0700, Blibbet wrote:
  Sounds good, thanks.
 
  OVMF/AAVMF is unfortunately non-free due to the FAT driver license.
  How are RedHat, Linaro etc dealing with that issue?
 
 The UEFI spec requires FAT for the ESP (EFI System Partition). Apple (an
 OEM and an OSV) ignores this and uses HFS+ for it's ESP. A Linux OEM
 could also choose to ignore FAT and use their own FS for their ESP.

It requires that you support FAT, which Apple does.  It does not require
that you can't support other filesystems.  That said, for us (Red Hat /
me / maintainers of various utilities) there's one big advantage to
using FAT over e.g. implementing and shipping an FS driver for some
other FS - it means our development and testing environments are closer
to that of commonly shipped machines.

 Having a FS that has some security would really be an improvement over
 storing firmware images on FAT, IMO.

Eh, it doesn't make much practical difference.  You just mount it in a
directory one level up that's got sufficiently strict permissions.

-- 
Peter


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150626211333.gb9...@redhat.com

Re: help? efivar 0.20-3 fails to build on arm64

[Blibbet]

 [...] it's worth noting that there *is* a Free-as-in-Freedom FAT
 driver ( https://github.com/pbatard/efifs ), but it's derived from grub
 code that's GPLv3, and that makes for some interesting legal questions
 as well since in at least some of the ovmf/aavmf builds we want Secure
 Boot enabled, and absent a whole lot of work that means linking openssl
 in.  I'm not even going to get in to thinking about which work is
 derivative of which between linking those three trees together.

The other day on the EDK2-devel list, someone wanted to contribute an
LGPL-licensed SmartCard driver to the TianoCore project, but they won't
take non-BSD stuff (except for FAT driver, of course).

OMVF targets aside, for real hardware, If GPL-derived code ends up in
Linux OEM's firmware volumes, it'll probably mean the OEM will have to
build the firmware, the existing IBVs will be too afraid to touch GPL code.

I wish some other UEFI Forum GPL-friendly vendors -- like Red Hat, SuSE,
Canonical -- would help create a place for non-BSD contributions to
TianoCore, so Linux OEMs can use them, and UEFI-based Linux-centric IBVs
can come into existance. :-)

In the current situation where Microsoft signs anything to be used on
Windows OEM's systems to work with Secure Boot, Microsoft as CA is free
to add restrictions to their signing, and non-GPLv3 is their main one
right now. Again, I don't see how UEFI can thrive on non-Windows systems
until the Windows OS vendor is stops being the CA for all non-Windows
OSes (except on Apple systems, ...unclear about ARM systems...) Isn't
there some community CA, like Software for Public Interest, or some
other org with CA abilities?


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/558dea3a.2070...@gmail.com

Re: help? efivar 0.20-3 fails to build on arm64

[Paul Wise]

On Fri, 2015-06-26 at 17:01 -0400, Peter Jones wrote:

 *ahem*,
 https://github.com/rhinstaller/efivar/commit/510b861012c111a362aa4c3da6ba408f2d78aaca

:) Thanks

 By not distributing it in Fedora, so far.  We've been looking at
 options, and it's worth noting that there *is* a Free-as-in-Freedom FAT
 driver ( https://github.com/pbatard/efifs ), but it's derived from grub
 code that's GPLv3, and that makes for some interesting legal questions
 as well since in at least some of the ovmf/aavmf builds we want Secure
 Boot enabled, and absent a whole lot of work that means linking openssl
 in.  I'm not even going to get in to thinking about which work is
 derivative of which between linking those three trees together.

Here is another possible option: 

http://elm-chan.org/fsw/ff/00index_e.html

Unfortunately the author attempted to make a 1-clause BSD license but
ended up creating a license without a clear grant of software freedom.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



signature.asc
Description: This is a digitally signed message part

Re: help? efivar 0.20-3 fails to build on arm64

[Paul Wise]

On Thu, Jun 25, 2015 at 10:16 AM, D. Jared Dominguez wrote:

 The moral of the story is that I uploaded efivar 0.20-4, which disables
 dh_auto_test, and it should stay that way.

Build-time tests should never affect the build system, I would suggest
talking upstream into splitting tests of the build system firmware out
of `make test` and into `make test-build-system-firmware` or the like.
There are probably some tests that don't interact with the build
system firmware?

It might also be interesting for edk2 (ovmf/qemu-efi) to run efivar to
test themselves.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6Hdwz_FZob_=Z8OTioa8kMxrPMHCf3EbP=d8mqd-pe...@mail.gmail.com

Re: help? efivar 0.20-3 fails to build on arm64

[Paul Wise]

On Fri, Jun 26, 2015 at 11:46 AM, Paul Wise wrote:

 We had a really interesting discussion about hardware/firmware testing
 on the debian-derivatives list recently, folks interested in that sort
 of stuff might be interested in looking at these links:

Another tool:

https://github.com/theopolis/uefi-firmware-parser
http://firmwaresecurity.com/2015/06/25/tool-mini-review-uefi-firmware-parser/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6FdN4cO0LMDv12LFTCY9jpNp-vmmpZky6ccsU=coi1...@mail.gmail.com

Re: help? efivar 0.20-3 fails to build on arm64

[Peter Jones]

On Thu, Jun 25, 2015 at 12:21:25AM +0100, Steve McIntyre wrote:
 On Wed, Jun 24, 2015 at 05:50:26PM -0500, D. Jared Dominguez wrote:
 Hi Wookey!
 
 Given that this package is correctly skipping the test on the non-UEFI
 machine, the correct fix would seem to be to fix the test on the UEFI
 machine.
 
 Yes, though Peter Jones told me after I sent the initial email: I would
 recommend not running it during a normal build. He's got some open issues
 with the test suite that he's concluded are due to broken firmware, not
 efivar being broken. I disabled dh_auto_test. I'll enable it again once Peter
 deems it more ready, though he noted that he thinks it makes more sense to
 rig up the tests in jenkins, which is on his to-do list.

Just to be clear there are a couple of problems with the test suite that
are probably legitimately my problem as well :/ .

 I'd be worried about running tests on a buildd that may actually
 permanently affect the hardware of the buildd! Simple read-only tests
 that verify some of the behaviour of efivar might make sense as part
 of the build verification, but nothing that attempts to write, imho.
 
 Unless there's an emulation layer that could be used to test efivar
 behaviour in a test harness, that would be lovely. And lots of work, I
 know!

Well, my plan is to set up a jenkins instance that runs the tests under
OVMF/AAVMF.  So they'd just be being backed to a file, not to a flash
part.

 How does this work on the x86 buildds? I'm not sure what the state of
 those is wrt UEFI either...

All hardware is terrible, but the confluence of bugs in the test suite
and bugs in the firmware seems to be stronger on aarch64 at the moment -
part of this is that the code has simply been used on x86_64 much more,
and part of it is that machines like Mustang have had a lot less
validation - real world or otherwise - than the commercially available
x86_64 UEFI machines.  And part of it is that you're running some of the
builds on non-UEFI machines, and on those machines the test suite just
returns success.

But I wouldn't run the test suite during the build in any case, because
it does often cause machines to be unusable without some physical
intervention - but usually these days that's just a reboot so the
firmware will do a GC cycle on the flash, sometimes it means manually
removing some variables and rebooting a second time, etc.  (Not every
vendor has Samsung's quality control department.)

-- 
Peter


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150625143151.gb20...@redhat.com

Re: help? efivar 0.20-3 fails to build on arm64

[Peter Jones]

On Thu, Jun 25, 2015 at 03:44:16PM +0800, Paul Wise wrote:
 On Thu, Jun 25, 2015 at 10:16 AM, D. Jared Dominguez wrote:
 
  The moral of the story is that I uploaded efivar 0.20-4, which disables
  dh_auto_test, and it should stay that way.
 
 Build-time tests should never affect the build system, I would suggest
 talking upstream into splitting tests of the build system firmware out
 of `make test` and into `make test-build-system-firmware` or the like.
 There are probably some tests that don't interact with the build
 system firmware?

The thing is, *all* the library does is provide a C API for interactions
with firmware.  So that's really what make test exercises, which is
why a) it's more useful for did my changes break anything during
development than anything else, b) it just shouldn't be run in a normal
package build, and c) it trips up on firmware interaction a lot when the
firmware isn't very mature.

 It might also be interesting for edk2 (ovmf/qemu-efi) to run efivar to
 test themselves.

Yeah, that's definitely a good idea.  My plan for make test has been
to orchestrate it with Jenkins (which we're using for other things here)
using OVMF/AAVMF, along with test suites for a bunch of the other UEFI
utilities we maintain.  I've got some local work in progress towards
that for shim, fwupdate, and efibootmgr; when I'm a bit farther along
it'll be very easy to add efivar to that.  That work is on hold right
now while we do a product release, but it should ramp up pretty strongly
in a couple of weeks.

The hard part will be making the Jenkins results public, because the
machines it'll actually run on are internal here.  That's a problem we
have for other projects as well :/ .  That said, I'll definitely push
all the actual code for it to a public repo, so others can easily
reproduce the results etc., so we can use them with LUV and similar.

-- 
Peter


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150625150532.gc20...@redhat.com

Re: help? efivar 0.20-3 fails to build on arm64

[Paul Wise]

On Thu, 2015-06-25 at 11:05 -0400, Peter Jones wrote:

 The thing is, *all* the library does is provide a C API for interactions
 with firmware.  So that's really what make test exercises, which is
 why a) it's more useful for did my changes break anything during
 development than anything else, b) it just shouldn't be run in a normal
 package build, and c) it trips up on firmware interaction a lot when the
 firmware isn't very mature.

The best way to avoid b) is to rename it to something other than test
or check since Debian and probably other distros automatically run
those make targets.

Some possible alternative options:

make developer-tests
make maybe-break-my-system-please ;)

  It might also be interesting for edk2 (ovmf/qemu-efi) to run efivar to
  test themselves.
 
 Yeah, that's definitely a good idea.  My plan for make test has been...

Sounds good, thanks.

OVMF/AAVMF is unfortunately non-free due to the FAT driver license.
How are RedHat, Linaro etc dealing with that issue?

We had a really interesting discussion about hardware/firmware testing
on the debian-derivatives list recently, folks interested in that sort
of stuff might be interested in looking at these links:

http://biosbits.org/
https://launchpad.net/fwts
https://github.com/chipsec/chipsec
https://github.com/01org/luv-yocto
http://www.inquisitor.ru/doc/einarc/
http://www.phoronix-test-suite.com/
https://bugs.debian.org/748783

The discussion was in the Inquisitor thread here:

https://lists.debian.org/debian-derivatives/2015/06/threads.html#00020

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



signature.asc
Description: This is a digitally signed message part

Re: help? efivar 0.20-3 fails to build on arm64

[D. Jared Dominguez]

On Wed, Jun 24, 2015 at 03:47:13PM -0500, Dominguez, Jared wrote:

So I just got an email about efivar 0.20-3 failing to build only on
arm64. See the log here:

https://buildd.debian.org/status/fetch.php?pkg=efivararch=arm64ver=0.20-3stamp=1435172463

I notice that the failure happens in dh_auto_test:

   dh_auto_test -a
make -j1 test
make[1]: Entering directory '/«PKGBUILDDIR»'
make -C src TOPDIR=/«PKGBUILDDIR» SRCDIR=/«PKGBUILDDIR»/src/
ARCH=aarch64
make[2]: Entering directory '/«PKGBUILDDIR»/src'
make[3]: Entering directory '/«PKGBUILDDIR»/src/test'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/«PKGBUILDDIR»/src/test'
make[2]: Leaving directory '/«PKGBUILDDIR»/src'
make -C docs TOPDIR=/«PKGBUILDDIR» SRCDIR=/«PKGBUILDDIR»/docs/
ARCH=aarch64
make[2]: Entering directory '/«PKGBUILDDIR»/docs'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/«PKGBUILDDIR»/docs'
make[2]: Entering directory '/«PKGBUILDDIR»/src'
make[3]: Entering directory '/«PKGBUILDDIR»/src/test'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/«PKGBUILDDIR»/src/test'
make -C test TOPDIR=/«PKGBUILDDIR» SRCDIR=/«PKGBUILDDIR»/src/ test
make[3]: Entering directory '/«PKGBUILDDIR»/src/test'
./tester
FAIL: one(line 111) (-1) set test failed: Permission denied
About to test empty
testing efi_set_variable()
testing efi_get_variable_size()
testing efi_get_variable()
testing efi_get_variable_attributes()
testing efi_del_variable()
testing efi_set_variable() with too many arguments
testing efi_append_variable()
testing efi_get_variable()
testing efi_del_variable()
About to test one
testing efi_set_variable()
make[3]: *** [test] Error 1
Makefile:18: recipe for target 'test' failed
make[2]: *** [test] Error 2
make[3]: Leaving directory '/«PKGBUILDDIR»/src/test'
Makefile:100: recipe for target 'test' failed
make[2]: Leaving directory '/«PKGBUILDDIR»/src'
make[1]: *** [test] Error 2
Makefile:23: recipe for target 'test' failed
make[1]: Leaving directory '/«PKGBUILDDIR»'
dh_auto_test: make -j1 test returned exit code 2
make: *** [build-arch] Error 2



But then I looked at the log for 0.20-2:

https://buildd.debian.org/status/fetch.php?pkg=efivararch=arm64ver=0.20-2stamp=1435096092


   dh_auto_test -a
make -j1 test
make[1]: Entering directory '/«PKGBUILDDIR»'
make -C src TOPDIR=/«PKGBUILDDIR» SRCDIR=/«PKGBUILDDIR»/src/
ARCH=aarch64
make[2]: Entering directory '/«PKGBUILDDIR»/src'
make[3]: Entering directory '/«PKGBUILDDIR»/src/test'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/«PKGBUILDDIR»/src/test'
make[2]: Leaving directory '/«PKGBUILDDIR»/src'
make -C docs TOPDIR=/«PKGBUILDDIR» SRCDIR=/«PKGBUILDDIR»/docs/
ARCH=aarch64
make[2]: Entering directory '/«PKGBUILDDIR»/docs'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/«PKGBUILDDIR»/docs'
make[2]: Entering directory '/«PKGBUILDDIR»/src'
make[3]: Entering directory '/«PKGBUILDDIR»/src/test'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/«PKGBUILDDIR»/src/test'
make -C test TOPDIR=/«PKGBUILDDIR» SRCDIR=/«PKGBUILDDIR»/src/ test
make[3]: Entering directory '/«PKGBUILDDIR»/src/test'
./tester
UEFI variables not supported on this machine.
make[3]: Leaving directory '/«PKGBUILDDIR»/src/test'
make[2]: Leaving directory '/«PKGBUILDDIR»/src'
make[2]: Entering directory '/«PKGBUILDDIR»/docs'
make[2]: Nothing to be done for 'test'.
make[2]: Leaving directory '/«PKGBUILDDIR»/docs'
make[1]: Leaving directory '/«PKGBUILDDIR»'


Well, okay, and it seems that generally builds succeed when the arm64
system doesn't support UEFI variables:
https://buildd.debian.org/status/logs.php?pkg=efivararch=arm64

So then, I've got questions:
1. Are some of the arm64 buildd's UEFI-enabled and some not? If so,
should they actually be segmented?
2. Would someone involved in the arm64 port be willing to look at this
build issue? Alternatively, I would need access to an arm64 system.

--Jared


Okay, so I talked to upstream, and he says I should only run make test 
for efivar if I'm actually doing development. Otherwise, I'm more likely 
to run into firmware bugs than actual bugs in efivar. #2 is not an 
important question then.


#1 still is relevant.

--
Jared Domínguez
Infrastructure Software Engineering
Dell | Enterprise Solutions Group


--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150624210242.gu4...@dell.com

Re: help? efivar 0.20-3 fails to build on arm64

[Wookey]

+++ D. Jared Dominguez [2015-06-24 15:47 -0500]:
 So I just got an email about efivar 0.20-3 failing to build only on
 arm64. See the log here:
 
 https://buildd.debian.org/status/fetch.php?pkg=efivararch=arm64ver=0.20-3stamp=1435172463
 
 I notice that the failure happens in dh_auto_test:
 
dh_auto_test -a
 make -j1 test

 make[3]: Entering directory '/«PKGBUILDDIR»/src/test'
 ./tester
 FAIL: one(line 111) (-1) set test failed: Permission denied
 About to test one
 testing efi_set_variable()
 make[3]: *** [test] Error 1
 
 
 But then I looked at the log for 0.20-2:
 
 https://buildd.debian.org/status/fetch.php?pkg=efivararch=arm64ver=0.20-2stamp=1435096092
 
 
dh_auto_test -a
 make -j1 test
 make[3]: Entering directory '/«PKGBUILDDIR»/src/test'
 ./tester
 UEFI variables not supported on this machine.
 
 Well, okay, and it seems that generally builds succeed when the
 arm64 system doesn't support UEFI variables:
 https://buildd.debian.org/status/logs.php?pkg=efivararch=arm64
 
 So then, I've got questions:
 1. Are some of the arm64 buildd's UEFI-enabled and some not? If so,
 should they actually be segmented?

0.20-2 built on arm-linaro-03 which is an APM Mustang.
0.20-3 built on arm-arm-01 which is ARM Juno.

That APM box still uses uboot. Juno uses UEFI. So I guess that
explains the problem. I believe that UEFI support for the APM hardware
does exist now, but those are early machines. I'm not sure if there is
a plan to upgrade them as mostly it doesn't matter. 

Given that this package is correctly skipping the test on the non-UEFI
machine, the correct fix would seem to be to fix the test on the UEFI
machine.

 2. Would someone involved in the arm64 port be willing to look at
 this build issue? Alternatively, I would need access to an arm64
 system.

Yep, we can have a look at this. Can you explina what the test is
testing? That should help debug it.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150624211534.gb21...@halon.org.uk

Re: help? efivar 0.20-3 fails to build on arm64

[D. Jared Dominguez]

Hi Wookey!

On Wed, Jun 24, 2015 at 04:15:34PM -0500, Wookey wrote:

So then, I've got questions:
1. Are some of the arm64 buildd's UEFI-enabled and some not? If so,
should they actually be segmented?


0.20-2 built on arm-linaro-03 which is an APM Mustang.
0.20-3 built on arm-arm-01 which is ARM Juno.

That APM box still uses uboot. Juno uses UEFI. So I guess that
explains the problem. I believe that UEFI support for the APM hardware
does exist now, but those are early machines. I'm not sure if there is
a plan to upgrade them as mostly it doesn't matter.


Ah, Mustang. :) It makes sense to me that we'd just leave those systems 
alone. If it's (mostly) not broken, don't fix it.



Given that this package is correctly skipping the test on the non-UEFI
machine, the correct fix would seem to be to fix the test on the UEFI
machine.


Yes, though Peter Jones told me after I sent the initial email: I would 
recommend not running it during a normal build. He's got some open 
issues with the test suite that he's concluded are due to broken 
firmware, not efivar being broken. I disabled dh_auto_test. I'll enable 
it again once Peter deems it more ready, though he noted that he thinks 
it makes more sense to rig up the tests in jenkins, which is on his 
to-do list.



2. Would someone involved in the arm64 port be willing to look at
this build issue? Alternatively, I would need access to an arm64
system.


Yep, we can have a look at this. Can you explina what the test is
testing? That should help debug it.


Honestly, I haven't looked at what they're testing because they weren't 
causing a problem for me until now. Peter would be the authority on 
that.


--Jared


--
Jared Domínguez
Infrastructure Software Engineering
Dell | Enterprise Solutions Group


--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150624225026.gx4...@dell.com

Re: help? efivar 0.20-3 fails to build on arm64

[Steve McIntyre]

On Wed, Jun 24, 2015 at 05:50:26PM -0500, D. Jared Dominguez wrote:
Hi Wookey!

Given that this package is correctly skipping the test on the non-UEFI
machine, the correct fix would seem to be to fix the test on the UEFI
machine.

Yes, though Peter Jones told me after I sent the initial email: I would
recommend not running it during a normal build. He's got some open issues
with the test suite that he's concluded are due to broken firmware, not
efivar being broken. I disabled dh_auto_test. I'll enable it again once Peter
deems it more ready, though he noted that he thinks it makes more sense to
rig up the tests in jenkins, which is on his to-do list.

I'd be worried about running tests on a buildd that may actually
permanently affect the hardware of the buildd! Simple read-only tests
that verify some of the behaviour of efivar might make sense as part
of the build verification, but nothing that attempts to write, imho.

Unless there's an emulation layer that could be used to test efivar
behaviour in a test harness, that would be lovely. And lots of work, I
know!

How does this work on the x86 buildds? I'm not sure what the state of
those is wrt UEFI either...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
I've only once written 'SQL is my bitch' in a comment. But that code 
 is in use on a military site... -- Simon Booth


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150624232125.gj4...@einval.com

Re: help? efivar 0.20-3 fails to build on arm64

[D. Jared Dominguez]

How does this work on the x86 buildds? I'm not sure what the state of
those is wrt UEFI either...

So, uh, funny that you should mention that. I realized that I build on a 
system that is legacy boot only... and the buildd's don't seem to 
rebuild. (I wish they would because the amd64 archive mostly holding 
binaries that have been built locally on developer machines creeps me 
out.)

I went and built on a UEFI-booting system and realized that efivar's 
make test needs to run as root because it's writing UEFI variables 
(duh). Well, so if I go manually sudo ./src/test/tester, it runs fine 
until it doesn't, presumably because it looks like it tests running a 
bunch of variable operations on progressively larger UEFI variables 
until they fail. (You probably don't want to run make test on certain 
Samsung laptops. :)

The moral of the story is that I uploaded efivar 0.20-4, which disables 
dh_auto_test, and it should stay that way.

I think that answers my questions.

--Jared


-- 
Jared Domínguez
Infrastructure Software Engineering
Dell | Enterprise Solutions Group


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150625021559.gb4...@dell.com

Re: Help with the arm64 and ppc64el installation-guides needed

[Michael Felt]

And last little bit - what is the linux world thinking - spaces in file
names? Good grief. (as well as very long names).

root@jessie:/etc/NetworkManager# ls -l system*
total 4
-rw--- 1 root root 260 May  1 22:44 Wired connection 1


On Sun, May 3, 2015 at 2:49 PM, Michael Felt aixto...@gmail.com wrote:

 Maybe something else to add to the release notes - the new
 /etc/NetworkManager/* (I hate long names and caps - I know this is not
 UNIX, but one of the goals of UNIX was to keep things short, fewer key
 presses, and less output (the example given was IBM 'mainframe' that gave a
 page of text for a command that had no output - making it much easier to
 start the 'pipe' concept - only send the output) compared to /etc/network/*
 for configuring (static) interfaces.

 imho a real pain - every distribution of Linux has a different way of
 doing things (although I am beginning to think it is a different version of
 Linux - change things because we can - because every distribution of Linux
 seems to be a different version of Linux).

 Previous UNIX vendors would have been hung out to dry for this kind of
 'change management (read mis-management). (imho).

 Anyway, please add NetworkManager - and other core Linux changes, or a
 link to 'Linux-world' changes - although I would expect Debian to take
 responsibility for the list of changes between:
 Linux wheezy 3.2.0-4-powerpc64 #1 SMP Debian 3.2.68-1+deb7u1 ppc64
 GNU/Linux
 and
 Linux jessie 3.16.0-4-powerpc64 #1 SMP Debian 3.16.7-ckt9-3 (2015-04-23)
 ppc64 GNU/Linux

 my two cents.

 On Sat, May 2, 2015 at 2:16 PM, Ben Hutchings b...@decadent.org.uk wrote:

 On Sat, 2015-05-02 at 11:15 +0200, Michael Felt wrote:
 [...]

  BTW: I notice a slight difference in how 'login as root' works between
  wheezy and jessie. On both systems I have enabled 'root login' for my
  initial tests. With wheezy I cannot login as root on the console, but
  can login using ssh. On Jessie this is the reverse. I assume this is
  deliberate.
 [...]

 The ssh part: yes, and that's documented in the release notes:
 
 https://www.debian.org/releases/jessie/powerpc/release-notes/ch-information.en.html#openssh
 .

 The console part: I don't think so; this is probably a bug in wheezy.
 The last time I had that sort of problem, it was due to an omission from
 the file /etc/securetty (list of devices that root may log in through).
 But in wheezy that file does include hvc0.

 Ben.

 --
 Ben Hutchings
 Q.  Which is the greater problem in the world today, ignorance or apathy?
 A.  I don't know and I couldn't care less.

Re: Help with the arm64 and ppc64el installation-guides needed

[Michael Felt]

Maybe something else to add to the release notes - the new
/etc/NetworkManager/* (I hate long names and caps - I know this is not
UNIX, but one of the goals of UNIX was to keep things short, fewer key
presses, and less output (the example given was IBM 'mainframe' that gave a
page of text for a command that had no output - making it much easier to
start the 'pipe' concept - only send the output) compared to /etc/network/*
for configuring (static) interfaces.

imho a real pain - every distribution of Linux has a different way of doing
things (although I am beginning to think it is a different version of Linux
- change things because we can - because every distribution of Linux seems
to be a different version of Linux).

Previous UNIX vendors would have been hung out to dry for this kind of
'change management (read mis-management). (imho).

Anyway, please add NetworkManager - and other core Linux changes, or a link
to 'Linux-world' changes - although I would expect Debian to take
responsibility for the list of changes between:
Linux wheezy 3.2.0-4-powerpc64 #1 SMP Debian 3.2.68-1+deb7u1 ppc64 GNU/Linux
and
Linux jessie 3.16.0-4-powerpc64 #1 SMP Debian 3.16.7-ckt9-3 (2015-04-23)
ppc64 GNU/Linux

my two cents.

On Sat, May 2, 2015 at 2:16 PM, Ben Hutchings b...@decadent.org.uk wrote:

 On Sat, 2015-05-02 at 11:15 +0200, Michael Felt wrote:
 [...]

  BTW: I notice a slight difference in how 'login as root' works between
  wheezy and jessie. On both systems I have enabled 'root login' for my
  initial tests. With wheezy I cannot login as root on the console, but
  can login using ssh. On Jessie this is the reverse. I assume this is
  deliberate.
 [...]

 The ssh part: yes, and that's documented in the release notes:
 
 https://www.debian.org/releases/jessie/powerpc/release-notes/ch-information.en.html#openssh
 .

 The console part: I don't think so; this is probably a bug in wheezy.
 The last time I had that sort of problem, it was due to an omission from
 the file /etc/securetty (list of devices that root may log in through).
 But in wheezy that file does include hvc0.

 Ben.

 --
 Ben Hutchings
 Q.  Which is the greater problem in the world today, ignorance or apathy?
 A.  I don't know and I couldn't care less.

Re: Help with the arm64 and ppc64el installation-guides needed

[Michael Felt]

By the way - I just looked at your installation instructions and I did not
find anything about how to install in POWER Server environment, i.e., as a
virtual machine (aka LPAR) on IBM POWER5 and later.
The ppc64le using KVM will obviously be different, but people using powerpc
(historically 32-bit - is that correct, and why I cannot  SMOKE perl with
-Duse64bitall ?).

Anyway - I have an installation 'story' I wrote up quite a while ago.
http://www.rootvg.net/content/view/560/88/ I just reused this procedure to
install Jessie and it still works fine. I like the command-line install
very much. One of my reasons that debian is my personal favorite for Linux
on Power.

BTW: I notice a slight difference in how 'login as root' works between
wheezy and jessie. On both systems I have enabled 'root login' for my
initial tests. With wheezy I cannot login as root on the console, but can
login using ssh. On Jessie this is the reverse. I assume this is
deliberate. (I'll open a new thread to ask how to manage this, because
sshd_config - which I know - seems to permit RootLogin (--without-password)
but I have not managed to get it to work. Normally I do not want this, but
for testing - logging in as root is how I start learning many things (i.e.,
I skip installing sudo and sudo su -).

So, the question for here - regarding documentation - is there a CHANGES
document I have missed that summarizes and/or details the changes
(intended) between wheezy and jessie?

Michael

On Mon, Apr 13, 2015 at 9:46 PM, Holger Wansing li...@wansing-online.de
wrote:

 Hi,

 Lennart Sorensen lsore...@csclub.uwaterloo.ca wrote:
  On Mon, Apr 13, 2015 at 09:37:42PM +0200, Holger Wansing wrote:
   Hi,
  
   Samuel Thibault sthiba...@debian.org wrote:
Holger Wansing, le Sat 11 Apr 2015 17:13:06 +0200, a écrit :
 +arch_porturl=ppc64el
 +arch_listname=ppc64el
   
Please take care when updating these to be sure to understand
what they mean. http://www.debian.org/ports/ppc64el and
http://lists.debian.org/debian-ppc64el don't exist.
  
   I knew this!
   But there needs to be created a site under
   http://www.debian.org/ports/ for ppc64el, when ppc64el gets a release
 arch.
   The only page for ppc64el on the ports page ATM is on the debian wiki.
   That will have to be changed.
   Otherwise that above entity in our d-i manual will fail to work, no
   matter which arch name you choose.
 
  I would think that just like armhf uses the debian-arm list, ppc64el
  will continue to use the debian-powerpc list.

 Yeah, I just saw that Samuel left the above entities at powerpc.
 That does of course work :-)


 Holger

 --
 
 Created with Sylpheed 3.2.0 under
 D E B I A N   L I N U X   7 . 0   W H E E Z Y !

 Registered Linux User #311290 - https://linuxcounter.net/
 


 --
 To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive:
 https://lists.debian.org/20150413214642.d550d8d8f90c341da72e7...@wansing-online.de

Re: Help with the arm64 and ppc64el installation-guides needed

[Ben Hutchings]

On Sat, 2015-05-02 at 11:15 +0200, Michael Felt wrote:
[...]

 BTW: I notice a slight difference in how 'login as root' works between
 wheezy and jessie. On both systems I have enabled 'root login' for my
 initial tests. With wheezy I cannot login as root on the console, but
 can login using ssh. On Jessie this is the reverse. I assume this is
 deliberate.
[...]

The ssh part: yes, and that's documented in the release notes:
https://www.debian.org/releases/jessie/powerpc/release-notes/ch-information.en.html#openssh.

The console part: I don't think so; this is probably a bug in wheezy.
The last time I had that sort of problem, it was due to an omission from
the file /etc/securetty (list of devices that root may log in through).
But in wheezy that file does include hvc0.

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today, ignorance or apathy?
A.  I don't know and I couldn't care less.


signature.asc
Description: This is a digitally signed message part

Re: Help with the arm64 and ppc64el installation-guides needed

[Michael Felt]

Just read the link re: PermitRoot --without-password

My comment - typical developer string - because many people are looking
for passwordless login for root, and from my UNIX background I would take
--without-password very literally. I suspect what is intended is
--no-password-auth-permitted, meaning some other form of authentication
is accepted, e.g., PKI.

Because of the comment in sshd_config I was thinking it was something in
the PAM configuration I needed to look at. And, FYI - if you follow the
suggestion in the sshd_config (re PAM) no login for anyone (using passwords
at least) is permitted.

Thank you for the link - I shall copy my keys in (later) and report back.
And secondly, for the link - for the changes history! Excellent!

Michael

On Sat, May 2, 2015 at 6:19 PM, Michael Felt aixto...@gmail.com wrote:

 Maybe - last time I tried - I mistyped the login - because login from
 console is working for both - thanks for the reply.

 re: root login on sshd - guess I need to read more carefully. I know about
 the cipher changes starting with OpenSSH 6.7, but had not yet stumbled on
 anything extra blocking root login.

 My apologies for a false statement! Must test again and again (so I will
 have to reload ubuntu, opensles and fedora to see which ones of those
 refuse root login at console. If both are blocked (with the newer openssh)
 may make some maintenance work difficult.

 Further - any interest in a different (in what way please) story on
 installing debian on PowerVM enabled systems?

 On Sat, May 2, 2015 at 2:16 PM, Ben Hutchings b...@decadent.org.uk wrote:

 On Sat, 2015-05-02 at 11:15 +0200, Michael Felt wrote:
 [...]

  BTW: I notice a slight difference in how 'login as root' works between
  wheezy and jessie. On both systems I have enabled 'root login' for my
  initial tests. With wheezy I cannot login as root on the console, but
  can login using ssh. On Jessie this is the reverse. I assume this is
  deliberate.
 [...]

 The ssh part: yes, and that's documented in the release notes:
 
 https://www.debian.org/releases/jessie/powerpc/release-notes/ch-information.en.html#openssh
 .

 The console part: I don't think so; this is probably a bug in wheezy.
 The last time I had that sort of problem, it was due to an omission from
 the file /etc/securetty (list of devices that root may log in through).
 But in wheezy that file does include hvc0.

 Ben.

 --
 Ben Hutchings
 Q.  Which is the greater problem in the world today, ignorance or apathy?
 A.  I don't know and I couldn't care less.

Re: Help with the arm64 and ppc64el installation-guides needed

[Michael Felt]

Maybe - last time I tried - I mistyped the login - because login from
console is working for both - thanks for the reply.

re: root login on sshd - guess I need to read more carefully. I know about
the cipher changes starting with OpenSSH 6.7, but had not yet stumbled on
anything extra blocking root login.

My apologies for a false statement! Must test again and again (so I will
have to reload ubuntu, opensles and fedora to see which ones of those
refuse root login at console. If both are blocked (with the newer openssh)
may make some maintenance work difficult.

Further - any interest in a different (in what way please) story on
installing debian on PowerVM enabled systems?

On Sat, May 2, 2015 at 2:16 PM, Ben Hutchings b...@decadent.org.uk wrote:

 On Sat, 2015-05-02 at 11:15 +0200, Michael Felt wrote:
 [...]

  BTW: I notice a slight difference in how 'login as root' works between
  wheezy and jessie. On both systems I have enabled 'root login' for my
  initial tests. With wheezy I cannot login as root on the console, but
  can login using ssh. On Jessie this is the reverse. I assume this is
  deliberate.
 [...]

 The ssh part: yes, and that's documented in the release notes:
 
 https://www.debian.org/releases/jessie/powerpc/release-notes/ch-information.en.html#openssh
 .

 The console part: I don't think so; this is probably a bug in wheezy.
 The last time I had that sort of problem, it was due to an omission from
 the file /etc/securetty (list of devices that root may log in through).
 But in wheezy that file does include hvc0.

 Ben.

 --
 Ben Hutchings
 Q.  Which is the greater problem in the world today, ignorance or apathy?
 A.  I don't know and I couldn't care less.

Re: Help with the arm64 and ppc64el installation-guides needed

[Lennart Sorensen]

On Mon, Apr 13, 2015 at 09:37:42PM +0200, Holger Wansing wrote:
 Hi,
 
 Samuel Thibault sthiba...@debian.org wrote:
  Holger Wansing, le Sat 11 Apr 2015 17:13:06 +0200, a écrit :
   +arch_porturl=ppc64el
   +arch_listname=ppc64el
  
  Please take care when updating these to be sure to understand
  what they mean. http://www.debian.org/ports/ppc64el and
  http://lists.debian.org/debian-ppc64el don't exist.
 
 I knew this!
 But there needs to be created a site under 
 http://www.debian.org/ports/ for ppc64el, when ppc64el gets a release arch.
 The only page for ppc64el on the ports page ATM is on the debian wiki.
 That will have to be changed.
 Otherwise that above entity in our d-i manual will fail to work, no 
 matter which arch name you choose.

I would think that just like armhf uses the debian-arm list, ppc64el
will continue to use the debian-powerpc list.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150413195056.gl29...@csclub.uwaterloo.ca

Re: Help with the arm64 and ppc64el installation-guides needed

[Holger Wansing]

Hi,

Lennart Sorensen lsore...@csclub.uwaterloo.ca wrote:
 On Mon, Apr 13, 2015 at 09:37:42PM +0200, Holger Wansing wrote:
  Hi,
  
  Samuel Thibault sthiba...@debian.org wrote:
   Holger Wansing, le Sat 11 Apr 2015 17:13:06 +0200, a écrit :
+arch_porturl=ppc64el
+arch_listname=ppc64el
   
   Please take care when updating these to be sure to understand
   what they mean. http://www.debian.org/ports/ppc64el and
   http://lists.debian.org/debian-ppc64el don't exist.
  
  I knew this!
  But there needs to be created a site under 
  http://www.debian.org/ports/ for ppc64el, when ppc64el gets a release arch.
  The only page for ppc64el on the ports page ATM is on the debian wiki.
  That will have to be changed.
  Otherwise that above entity in our d-i manual will fail to work, no 
  matter which arch name you choose.
 
 I would think that just like armhf uses the debian-arm list, ppc64el
 will continue to use the debian-powerpc list.

Yeah, I just saw that Samuel left the above entities at powerpc.
That does of course work :-)


Holger

-- 

Created with Sylpheed 3.2.0 under
D E B I A N   L I N U X   7 . 0   W H E E Z Y !

Registered Linux User #311290 - https://linuxcounter.net/



--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150413214642.d550d8d8f90c341da72e7...@wansing-online.de

Re: Help with the arm64 and ppc64el installation-guides needed

[Holger Wansing]

Hi,

Samuel Thibault sthiba...@debian.org wrote:
 Holger Wansing, le Sat 11 Apr 2015 17:13:06 +0200, a écrit :
  +arch_porturl=ppc64el
  +arch_listname=ppc64el
 
 Please take care when updating these to be sure to understand
 what they mean. http://www.debian.org/ports/ppc64el and
 http://lists.debian.org/debian-ppc64el don't exist.

I knew this!
But there needs to be created a site under 
http://www.debian.org/ports/ for ppc64el, when ppc64el gets a release arch.
The only page for ppc64el on the ports page ATM is on the debian wiki.
That will have to be changed.
Otherwise that above entity in our d-i manual will fail to work, no 
matter which arch name you choose.


Holger

-- 

Created with Sylpheed 3.2.0 under
D E B I A N   L I N U X   7 . 0   W H E E Z Y !

Registered Linux User #311290 - https://linuxcounter.net/



--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150413213742.378bdfd52d69d650cb930...@wansing-online.de

Re: Help with the arm64 and ppc64el installation-guides needed

[Cyril Brulebois]

Wookey woo...@wookware.org (2015-04-13):
 OK. I've done this. I don't seem to have commit rights (should I?)
 Sendingen/hardware/supported/arm.xml
 Transmitting file data .svn: E13: Commit failed (details follow):
 svn: E13: Can't open file '/svn/d-i/db/txn-current-lock': Permission 
 denied

(I can't think of a reason why you shouldn't be part of the
debian-installer group, so I've just added you.)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Help with the arm64 and ppc64el installation-guides needed

[Lennart Sorensen]

On Mon, Apr 13, 2015 at 10:26:51AM -0300, Thadeu Lima de Souza Cascardo wrote:
 Well, bare metal has been mistakenly used to describe what I would call
 dedicated partition of single partition mode. People may call it bare
 metal, because there is no virtualized IO (in fact, there is the
 console), and CPU and memory resources are not shared with other
 partitions. But there is still a Hypervisor under the OS. It's still a
 PowerVM LPAR, and boot capabilities still apply as though you were
 sharing the server with other partitions.

So PowerVM is built into the firmware and is always running?  We certainly
did not order or install PowerVM in any way.

I do see in the boot messages that hvc is a virtual console.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150413140748.gk29...@csclub.uwaterloo.ca

Re: Help with the arm64 and ppc64el installation-guides needed

[Thadeu Lima de Souza Cascardo]

On Sun, Apr 12, 2015 at 09:43:07PM -0400, Lennart Sorensen wrote:
 On Sun, Apr 12, 2015 at 08:45:50PM -0300, Thadeu Lima de Souza Cascardo wrote:
  When it comes to IBM latest servers, that are three options for
  platforms: OPAL (powernv in Linux), as PowerKVM guest, and PowerVM LPAR
  (both pseries platform in Linux).
  
  OPAL has petitboot built-in, PowerKVM uses SLOF and PowerVM uses IBM
  Open Firmware. The three are capable of booting from optical media, USB,
  and netboot. With the exception of KVM guests, when a supported
  graphical card is used, graphical installation should be an option as
  well. For KVM guests, there is offb, which should work with VNC. Should
  we enable graphical installation in the media? Or is just netboot images
  missing graphical support on d-i?
 
 So does this mean that PowerVM LPAR is the same as running on the bare
 metal (which is the only way I have run debian on IBM pSeries systems,
 specifically a p520 power6+ and a p710 power7).  Certainly openfirmware
 booting with grub2 is the only method I have ever used.  IBM support
 people sure do seem confused when they hear you have no HMC or VM or
 anything else on your pSeries.  Just Debian on the bare metal.
 

Well, bare metal has been mistakenly used to describe what I would call
dedicated partition of single partition mode. People may call it bare
metal, because there is no virtualized IO (in fact, there is the
console), and CPU and memory resources are not shared with other
partitions. But there is still a Hypervisor under the OS. It's still a
PowerVM LPAR, and boot capabilities still apply as though you were
sharing the server with other partitions.

Hope that clarifies.

Cascardo.

 -- 
 Len Sorensen


signature.asc
Description: Digital signature

Re: Help with the arm64 and ppc64el installation-guides needed

[Samuel Thibault]

Breno Leitao, le Mon 13 Apr 2015 10:04:29 -0300, a écrit :
 Sorry, I answered your email twice regarding this topic and never heard back.
 
 I answered it initially in 2014-11-29[1] and later in 2014-12-18[2]. In both 
 cases
 I told about our patches to this repository.

I'm not subscribed to the debian-powerpc mailing list...

Samuel


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150413133927.gj3...@type.bordeaux.inria.fr

Re: Help with the arm64 and ppc64el installation-guides needed

[Breno Leitao]

Hi Samuel,

On 04/10/2015 07:24 PM, Samuel Thibault wrote:
 Hello,
 
 Breno Leitao, le Fri 10 Apr 2015 17:44:01 -0300, a écrit :
 On 04/09/2015 01:13 PM, Karsten Merker wrote: Hello everybody,
 the release date for Jessie is near, but the installation-guide
 does not seem to contain any arm64/ppc64el-specific information
 yet.
 We have created this installation guide, but unfortunatelly it was not 
 integrated yet.

 It is still on my github repository. Can you import it?
 
 Uh. I requested this very kind of information in september and
 november, why wasn't this work (done in december) ever submitted
 before?  
Sorry, I answered your email twice regarding this topic and never heard back.

I answered it initially in 2014-11-29[1] and later in 2014-12-18[2]. In both 
cases
I told about our patches to this repository.

[1] https://lists.debian.org/debian-powerpc/2014/12/msg00016.html
[2] https://lists.debian.org/debian-powerpc/2014/12/msg00025.html


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/552bbedd.9080...@br.ibm.com

Re: Help with the arm64 and ppc64el installation-guides needed

[Wookey]

+++ Karsten Merker [2015-04-09 18:13 +0200]:
 Hello everybody,
 
 the release date for Jessie is near, but the installation-guide
 does not seem to contain any arm64/ppc64el-specific information
 yet. It would be nice if those who are familiar with those
 platforms could provide patches against the installation guide,
 so that we can release with proper documentation.
 
 At least some basic information about the supported hardware
 for the overview at 
 
 https://jenkins.debian.net/userContent/installation-guide/installation-guide-arm64/en/ch02s01.html

OK. I've done this. I don't seem to have commit rights (should I?)
Sendingen/hardware/supported/arm.xml
Transmitting file data .svn: E13: Commit failed (details follow):
svn: E13: Can't open file '/svn/d-i/db/txn-current-lock': Permission denied

so patch attached.

I'll work on the 2nd part now.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/
Index: en/hardware/supported/arm.xml
===
--- en/hardware/supported/arm.xml	(revision 69739)
+++ en/hardware/supported/arm.xml	(working copy)
@@ -6,49 +6,57 @@
 
 para
 
-ARM systems are a lot more heterogenous than the i386/amd64-based PC
-architecture, where all systems share a common system firmware (BIOS or/and
-UEFI) which handles the board-specific basic hardware initialization in a
-standardized way.
+ARM systems are much more heterogenous than the i386/amd64-based PC
+architecture, so whilst 64-bit ARM machines should boot in a
+standardised way, like PCs, the situation is more complicated for
+32-bit ARM machines.
 
-The ARM architecture is used mainly in so-called quotesystems-on-chip/quote (SoCs). 
-These SoCs are designed by many different companies with vastly varying
-hardware components even for the very basic functionality required to bring
-the system up.  Systems using them usually lack a common system firmware
-interface and as a result, on ARM systems the Linux kernel has to take care
-of many system-specific low-level issues which are handled by the
-mainboard's BIOS in the PC world.
+/para
 
+para
+The ARM architecture is used mainly in so-called
+quotesystems-on-chip/quote (SoCs). These SoCs are designed by many
+different companies with vastly varying hardware components even for
+the very basic functionality required to bring the system up. System
+firmware interfaces have been increasingly standardised over time, but
+especially on older hardware firmware/boot interfaces vary a great
+deal, so on these systems the Linux kernel has to take care of many
+system-specific low-level issues which are handled by the mainboard's
+BIOS in the PC world.
+
 /para
 
 para
+At the beginning of the ARM support in the Linux kernel, the hardware
+variety resulted in the requirement of having a separate kernel for
+each ARM system in contrast to the quoteone-fits-all/quote kernel
+for PC systems.  As this approach does not scale to a large number of
+different systems, work was done to allow booting with a single ARM
+kernel that can run on different ARM systems.  Support for newer ARM
+systems gets implemented in a way that allows the use of such a
+multiplatform kernel, but for several older systems a seperate
+specific kernel is still required.
+/para
 
-At the beginning of the ARM support in the Linux kernel, this resulted in
-the requirement of having a seperate kernel for each ARM system in contrast
-to the quoteone-fits-all/quote kernel for PC systems.  As this approach does not
-scale to a large number of different systems, work has started to be able to
-provide a single ARM kernel that can run on different ARM systems.  Support
-for newer ARM systems gets implemented in a way that allows the use of such
-a multiplatform kernel, but for several older systems a seperate specific
-kernel is still required.
-
+para
 Because of this, the standard debian; distribution only supports
-installation on a selected number of older ARM systems in addition to the
-newer systems which are supported by the ARM multiplatform (armmp) kernel. 
+installation on a selected number of older 32-bit ARM systems in
+addition to the newer (32 and 64 -bit) systems which are supported by
+the ARM multiplatform kernels (called 'armmp' on 32-bit armhf, no
+flavour name on 64-bit arm64).
 
 /para
 
 para
-
 The ARM architecture has evolved over time and modern ARM processors provide
 features which are not available in older models.  debian; therefore
-provides two ARM ports, the debian;/armel and the debian;/armhf port. 
+provides three ARM ports: the debian;/arm64 port for all 64-bit machines, and the debian;/armel and the debian;/armhf ports for 32-bit machines. 
 debian;/armel targets older ARM processors without support for a hardware
 floating point unit (FPU), while debian;/armhf works only on newer ARM
 processors which implement at least the ARMv7 architecture with version 3 of
 the ARM vector floating point 

Re: Help with the arm64 and ppc64el installation-guides needed

[Steve McIntyre]

On Thu, Apr 09, 2015 at 06:13:50PM +0200, Karsten Merker wrote:
Hello everybody,

the release date for Jessie is near, but the installation-guide
does not seem to contain any arm64/ppc64el-specific information
yet. It would be nice if those who are familiar with those
platforms could provide patches against the installation guide,
so that we can release with proper documentation.

At least some basic information about the supported hardware
for the overview at 

https://jenkins.debian.net/userContent/installation-guide/installation-guide-arm64/en/ch02s01.html
https://jenkins.debian.net/userContent/installation-guide/installation-guide-ppc64el/en/ch02s01.html

For arm64, we have a generic kernel that (modulo DTB) should work on
all the supportable hardware, similar to i386 and amd64. I'd leave
this section blank for arm64, like for the x86 maybe? Or would people
rather see some text to describe the hardware as a single flavour,
like for the ppc64el case?

and information about available boot methods at

https://jenkins.debian.net/userContent/installation-guide/installation-guide-ppc64el/en/ch05s01.html
https://jenkins.debian.net/userContent/installation-guide/installation-guide-arm64/en/ch05s01.html

would be nice. Currently all documentation in the arm64/ppc64el
versions of the installation guide describes only the
corresponding 32bit-Platforms.

Right. This section is definitely going to need work for arm64, to
describe both U-Boot and UEFI boot options across platforms. I'm
looking it now, but it's going to need some time. I'm hoping to be
able to re-use some of the existing content from amd64 and armhf, at
least...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
I've only once written 'SQL is my bitch' in a comment. But that code 
 is in use on a military site... -- Simon Booth


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150412230508.gj1...@einval.com

Re: Help with the arm64 and ppc64el installation-guides needed

[Shawn Landden]

On Sun, Apr 12, 2015 at 6:43 PM, Lennart Sorensen
lsore...@csclub.uwaterloo.ca wrote:
 On Sun, Apr 12, 2015 at 08:45:50PM -0300, Thadeu Lima de Souza Cascardo wrote:
 Sorry for jumping in. I would like the chance to complement and clarify
 some things about ppc64el platform.

 As Aurelien pointed out, when used in OPAL mode, the system will boot a
 system running petitboot, which is capable of netboot, booting from
 disk, and install media.

 So, will it boot from USB media? Yes.

 When it comes to IBM latest servers, that are three options for
 platforms: OPAL (powernv in Linux), as PowerKVM guest, and PowerVM LPAR
 (both pseries platform in Linux).

 OPAL has petitboot built-in, PowerKVM uses SLOF and PowerVM uses IBM
 Open Firmware. The three are capable of booting from optical media, USB,
 and netboot. With the exception of KVM guests, when a supported
 graphical card is used, graphical installation should be an option as
 well. For KVM guests, there is offb, which should work with VNC. Should
 we enable graphical installation in the media? Or is just netboot images
 missing graphical support on d-i?

 So does this mean that PowerVM LPAR is the same as running on the bare
 metal (which is the only way I have run debian on IBM pSeries systems,
 specifically a p520 power6+ and a p710 power7).  Certainly openfirmware
 booting with grub2 is the only method I have ever used.  IBM support
 people sure do seem confused when they hear you have no HMC or VM or
 anything else on your pSeries.  Just Debian on the bare metal.

 One caveat: I may be mistaken on the current state of support for USB
 and netboot on SLOF. But considering it's a KVM guest using qemu, there
 is much more flexibility, if things are downloaded on the host. I would
 say that is one of the things that we should document on the
 installation-guide. Is that right?

 As for wireless network adapters, the systems don't ship with any, and I
 haven't heard of any testing with any drivers. Nonetheless, those
 systems support PCI 3.0 and USB 3.0, so there is no reason those
 adapters shouldn't work, giving enough testing and fixes. But I would
 leave that out.

 As for other systems supporting ppc64el, OpenPower members have been
 releasing new systems using Power8 and supporting little-endian from the
 start.

 As already mentioned, older IBM systems could be capable as well, but I
 wouldn't say that is supported. As for chips from Freescale, I can't
 tell much. For 64-bit capable old Macs, I suppose firmware could be a
 problem. For those systems, adopting ppc64 (BE) would offer an option.

 Why 64-bit? Well, the same answer applies for all platforms. Address
 space. I suppose some people cannot even run web browsers these days
 without 64-bit  :-). Of course, that has some disadvantages, like the
 memory footprint because of pointers, that x32 tries to address.

 I sometimes wonder if limiting the browser to 2GB of memory is a
 convinient way to prevent the leaks from getting out of hand in the
 terrible code that is in web browsers.
4GB when kernel is 64-bit

 --
 Len Sorensen


 --
 To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: https://lists.debian.org/20150413014307.gj29...@csclub.uwaterloo.ca




-- 
Liberty equality fraternity or death,

Shawn Landden
ChurchOfGit.com


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAJusiZXR-YYYBa1zOX_jBr=S0=iionb3s47zxe6ebyzvp9v...@mail.gmail.com

Re: Help with the arm64 and ppc64el installation-guides needed

[Lennart Sorensen]

On Sun, Apr 12, 2015 at 08:45:50PM -0300, Thadeu Lima de Souza Cascardo wrote:
 Sorry for jumping in. I would like the chance to complement and clarify
 some things about ppc64el platform.
 
 As Aurelien pointed out, when used in OPAL mode, the system will boot a
 system running petitboot, which is capable of netboot, booting from
 disk, and install media.
 
 So, will it boot from USB media? Yes.
 
 When it comes to IBM latest servers, that are three options for
 platforms: OPAL (powernv in Linux), as PowerKVM guest, and PowerVM LPAR
 (both pseries platform in Linux).
 
 OPAL has petitboot built-in, PowerKVM uses SLOF and PowerVM uses IBM
 Open Firmware. The three are capable of booting from optical media, USB,
 and netboot. With the exception of KVM guests, when a supported
 graphical card is used, graphical installation should be an option as
 well. For KVM guests, there is offb, which should work with VNC. Should
 we enable graphical installation in the media? Or is just netboot images
 missing graphical support on d-i?

So does this mean that PowerVM LPAR is the same as running on the bare
metal (which is the only way I have run debian on IBM pSeries systems,
specifically a p520 power6+ and a p710 power7).  Certainly openfirmware
booting with grub2 is the only method I have ever used.  IBM support
people sure do seem confused when they hear you have no HMC or VM or
anything else on your pSeries.  Just Debian on the bare metal.

 One caveat: I may be mistaken on the current state of support for USB
 and netboot on SLOF. But considering it's a KVM guest using qemu, there
 is much more flexibility, if things are downloaded on the host. I would
 say that is one of the things that we should document on the
 installation-guide. Is that right?
 
 As for wireless network adapters, the systems don't ship with any, and I
 haven't heard of any testing with any drivers. Nonetheless, those
 systems support PCI 3.0 and USB 3.0, so there is no reason those
 adapters shouldn't work, giving enough testing and fixes. But I would
 leave that out.
 
 As for other systems supporting ppc64el, OpenPower members have been
 releasing new systems using Power8 and supporting little-endian from the
 start.
 
 As already mentioned, older IBM systems could be capable as well, but I
 wouldn't say that is supported. As for chips from Freescale, I can't
 tell much. For 64-bit capable old Macs, I suppose firmware could be a
 problem. For those systems, adopting ppc64 (BE) would offer an option.
 
 Why 64-bit? Well, the same answer applies for all platforms. Address
 space. I suppose some people cannot even run web browsers these days
 without 64-bit  :-). Of course, that has some disadvantages, like the
 memory footprint because of pointers, that x32 tries to address.

I sometimes wonder if limiting the browser to 2GB of memory is a
convinient way to prevent the leaks from getting out of hand in the
terrible code that is in web browsers.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150413014307.gj29...@csclub.uwaterloo.ca

Re: Help with the arm64 and ppc64el installation-guides needed

[Samuel Thibault]

Aurelien Jarno, le Sun 12 Apr 2015 22:08:44 +0200, a écrit :
 On 2015-04-12 20:22, Samuel Thibault wrote:
  Since petitboot runs inside a running linux kernel, that only shifts the
  problem of booting that linux kernel :)
 
 Petitboot is the default bootloader on this machine when configured to
 run Linux. It's the interface the user see when powering up the machine.

Uh. Interesting :D

Thanks,
Samuel


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150412210608.ga2...@type.wlan.youpi.perso.aquilenet.fr

Re: Help with the arm64 and ppc64el installation-guides needed

[Ben Hutchings]

On Sun, 2015-04-12 at 22:04 +0200, Samuel Thibault wrote:
 Ben Hutchings, le Sun 12 Apr 2015 20:27:29 +0100, a écrit :
  On Sun, 2015-04-12 at 20:45 +0200, Samuel Thibault wrote:
   Ben Hutchings, le Sun 12 Apr 2015 00:35:33 +0100, a écrit :
On Sat, 2015-04-11 at 20:22 +0200, Holger Wansing wrote:
 supports-smp-sometimes - that generation of cpu will most likely
  fully support smp, right?
[...]

Yes.
   
   That's not the question here, see the bit of documentation that it
   enables: it's whether the *kernel* supports SMP by default, through
   SMP-alternatives, in a separate image, or not in any shipped image.
  
  There is only one kernel flavour, which of course supports SMP.  I don't
  think SMP-alternatives exist on anything but x86 and ARM, unfortunately.
 
 Ok, thanks.
 
  By the way, is this correctly documented for armhf?  Both of the armhf
  kernel flavours support SMP with SMP-alternatives.
 
 Apparently nobody updated build/arch-options/armhf in that regard. Note
 that smp_config_section and smp_config_option should also be set (they
 are the section and option that should be used to enable SMP when
 configuring Linux).

I've fixed these values (I hope) for armhf, arm64, mips and mipsel based
on the current kernel configurations.

Ben.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source


signature.asc
Description: This is a digitally signed message part

Re: Help with the arm64 and ppc64el installation-guides needed

[Samuel Thibault]

Ben Hutchings, le Sun 12 Apr 2015 23:13:34 +0100, a écrit :
 I've fixed these values (I hope) for armhf, arm64, mips and mipsel based
 on the current kernel configurations.

Thanks!

Samuel


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150412221805.ge2...@type.wlan.youpi.perso.aquilenet.fr

Re: Help with the arm64 and ppc64el installation-guides needed

[Cyril Brulebois]

Samuel Thibault sthiba...@debian.org (2015-04-12):
 Holger Wansing, le Sat 11 Apr 2015 17:13:06 +0200, a écrit :
  All that contained in attached patch for review.
  The manual builds fine with it.
 
 Thanks, I have fixed a couple more things and commited it.
 
 Cyril, when should we upload an updated installation guide to be ready
 for RC3?

Things are still a bit sketchy, but if we can have everything d-i
related uploaded/unblocked by friday 17th, that'd be nice.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Help with the arm64 and ppc64el installation-guides needed

[Thadeu Lima de Souza Cascardo]

On Sun, Apr 12, 2015 at 11:06:08PM +0200, Samuel Thibault wrote:
 Aurelien Jarno, le Sun 12 Apr 2015 22:08:44 +0200, a écrit :
  On 2015-04-12 20:22, Samuel Thibault wrote:
   Since petitboot runs inside a running linux kernel, that only shifts the
   problem of booting that linux kernel :)
  
  Petitboot is the default bootloader on this machine when configured to
  run Linux. It's the interface the user see when powering up the machine.
 
 Uh. Interesting :D
 
 Thanks,
 Samuel

Sorry for jumping in. I would like the chance to complement and clarify
some things about ppc64el platform.

As Aurelien pointed out, when used in OPAL mode, the system will boot a
system running petitboot, which is capable of netboot, booting from
disk, and install media.

So, will it boot from USB media? Yes.

When it comes to IBM latest servers, that are three options for
platforms: OPAL (powernv in Linux), as PowerKVM guest, and PowerVM LPAR
(both pseries platform in Linux).

OPAL has petitboot built-in, PowerKVM uses SLOF and PowerVM uses IBM
Open Firmware. The three are capable of booting from optical media, USB,
and netboot. With the exception of KVM guests, when a supported
graphical card is used, graphical installation should be an option as
well. For KVM guests, there is offb, which should work with VNC. Should
we enable graphical installation in the media? Or is just netboot images
missing graphical support on d-i?

One caveat: I may be mistaken on the current state of support for USB
and netboot on SLOF. But considering it's a KVM guest using qemu, there
is much more flexibility, if things are downloaded on the host. I would
say that is one of the things that we should document on the
installation-guide. Is that right?

As for wireless network adapters, the systems don't ship with any, and I
haven't heard of any testing with any drivers. Nonetheless, those
systems support PCI 3.0 and USB 3.0, so there is no reason those
adapters shouldn't work, giving enough testing and fixes. But I would
leave that out.

As for other systems supporting ppc64el, OpenPower members have been
releasing new systems using Power8 and supporting little-endian from the
start.

As already mentioned, older IBM systems could be capable as well, but I
wouldn't say that is supported. As for chips from Freescale, I can't
tell much. For 64-bit capable old Macs, I suppose firmware could be a
problem. For those systems, adopting ppc64 (BE) would offer an option.

Why 64-bit? Well, the same answer applies for all platforms. Address
space. I suppose some people cannot even run web browsers these days
without 64-bit  :-). Of course, that has some disadvantages, like the
memory footprint because of pointers, that x32 tries to address.

Regards.
Cascardo.


signature.asc
Description: Digital signature

Re: Help with the arm64 and ppc64el installation-guides needed

[Ben Hutchings]

On Sun, 2015-04-12 at 20:45 +0200, Samuel Thibault wrote:
 Ben Hutchings, le Sun 12 Apr 2015 00:35:33 +0100, a écrit :
  On Sat, 2015-04-11 at 20:22 +0200, Holger Wansing wrote:
   supports-smp-sometimes - that generation of cpu will most likely
fully support smp, right?
  [...]
  
  Yes.
 
 That's not the question here, see the bit of documentation that it
 enables: it's whether the *kernel* supports SMP by default, through
 SMP-alternatives, in a separate image, or not in any shipped image.

There is only one kernel flavour, which of course supports SMP.  I don't
think SMP-alternatives exist on anything but x86 and ARM, unfortunately.

By the way, is this correctly documented for armhf?  Both of the armhf
kernel flavours support SMP with SMP-alternatives.

Ben.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source


signature.asc
Description: This is a digitally signed message part

Re: Help with the arm64 and ppc64el installation-guides needed

[Samuel Thibault]

Holger Wansing, le Sat 11 Apr 2015 17:13:06 +0200, a écrit :
 +arch_porturl=ppc64el
 +arch_listname=ppc64el

Please take care when updating these to be sure to understand
what they mean. http://www.debian.org/ports/ppc64el and
http://lists.debian.org/debian-ppc64el don't exist.

Samuel


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150412183314.GE2969@type

Re: Help with the arm64 and ppc64el installation-guides needed

[Samuel Thibault]

Holger Wansing, le Sat 11 Apr 2015 21:20:37 +0200, a écrit :
 And: is there support for the graphical installer?
 As far as I can see, the images do not contain the graphical
 installer.

See the documentation we have for powerpc: we generate only the mini GTK
isos for it (on e.g.
http://ftp.nl.debian.org/debian/dists/testing/main/installer-powerpc/current/images/powerpc/netboot/gtk/
 ).
It seems we don't generate them for ppc64el, see
http://ftp.nl.debian.org/debian/dists/testing/main/installer-ppc64el/current/images/netboot/

Samuel


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150412183957.GG2969@type

Re: Help with the arm64 and ppc64el installation-guides needed

[Samuel Thibault]

Ben Hutchings, le Sun 12 Apr 2015 00:35:33 +0100, a écrit :
 On Sat, 2015-04-11 at 20:22 +0200, Holger Wansing wrote:
  supports-smp-sometimes - that generation of cpu will most likely
   fully support smp, right?
 [...]
 
 Yes.

That's not the question here, see the bit of documentation that it
enables: it's whether the *kernel* supports SMP by default, through
SMP-alternatives, in a separate image, or not in any shipped image.

Samuel


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150412184535.GH2969@type

Re: Help with the arm64 and ppc64el installation-guides needed

[Samuel Thibault]

Holger Wansing, le Sat 11 Apr 2015 17:13:06 +0200, a écrit :
 All that contained in attached patch for review.
 The manual builds fine with it.

Thanks, I have fixed a couple more things and commited it.

Cyril, when should we upload an updated installation guide to be ready
for RC3?

Samuel


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150412190109.GI2969@type

Re: Help with the arm64 and ppc64el installation-guides needed

[Samuel Thibault]

Hello,

Mmm, the following looks like a useless addition:

Holger Wansing, le Sat 11 Apr 2015 17:13:06 +0200, a écrit :
 Index: en/boot-installer/powerpc.xml
 ===
 --- en/boot-installer/powerpc.xml (Revision 69729)
 +++ en/boot-installer/powerpc.xml (Arbeitskopie)
 @@ -283,3 +283,41 @@
  
  /para
/sect2
 +
 +  sect2 arch=ppc64el titleBooting a ppc64el machine/title
 +para
 +
 +How to boot a ppc64el machine:
 +
 +/para
 +
 +  sect3 titlePetitboot/title
 +para
 +
 +Petitboot is a platform independent bootloader based on the Linux kexec.
 +Petitboot supports loading kernel, initrd and device tree files from 
 +any Linux mountable filesystem, plus can load files from the network 
 +using the FTP, SFTP, TFTP, NFS, HTTP and HTTPS protocols. Petitboot can
 +boot any operating system that includes kexec boot support.
 +
 +/parapara
 +
 +Petitboot looks for bootloader configuration files on mountable devices
 +in the system, and can also be configured to use boot information from a
 +DHCP server.
 +
 +/para
 +  /sect3
 +
 +!-- comment this out for now, since there is no content
 +  sect3 titleBoot parameters/title
 +para
 +Boot parameters for ppc64el
 +
 +FIXME: add some useful content here
 +
 +/para
 +  /sect3
 +--
 +
 +  /sect2

Since petitboot runs inside a running linux kernel, that only shifts the
problem of booting that linux kernel :)

Samuel


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150412182233.GD2969@type

Re: Help with the arm64 and ppc64el installation-guides needed

[Samuel Thibault]

Holger Wansing, le Sat 11 Apr 2015 20:22:49 +0200, a écrit :
 supports-floppy-boot - I think that arch has no floppy support

Does ppc64el supports booting from a USB stick?

Samuel


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150412183622.GF2969@type

Re: Help with the arm64 and ppc64el installation-guides needed

[Samuel Thibault]

Ben Hutchings, le Sun 12 Apr 2015 20:27:29 +0100, a écrit :
 On Sun, 2015-04-12 at 20:45 +0200, Samuel Thibault wrote:
  Ben Hutchings, le Sun 12 Apr 2015 00:35:33 +0100, a écrit :
   On Sat, 2015-04-11 at 20:22 +0200, Holger Wansing wrote:
supports-smp-sometimes - that generation of cpu will most likely
 fully support smp, right?
   [...]
   
   Yes.
  
  That's not the question here, see the bit of documentation that it
  enables: it's whether the *kernel* supports SMP by default, through
  SMP-alternatives, in a separate image, or not in any shipped image.
 
 There is only one kernel flavour, which of course supports SMP.  I don't
 think SMP-alternatives exist on anything but x86 and ARM, unfortunately.

Ok, thanks.

 By the way, is this correctly documented for armhf?  Both of the armhf
 kernel flavours support SMP with SMP-alternatives.

Apparently nobody updated build/arch-options/armhf in that regard. Note
that smp_config_section and smp_config_option should also be set (they
are the section and option that should be used to enable SMP when
configuring Linux).

Samuel


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150412200402.GL2969@type

Re: Help with the arm64 and ppc64el installation-guides needed

[Aurelien Jarno]

On 2015-04-12 20:22, Samuel Thibault wrote:
 Hello,
 
 Mmm, the following looks like a useless addition:
 
 Holger Wansing, le Sat 11 Apr 2015 17:13:06 +0200, a écrit :
  Index: en/boot-installer/powerpc.xml
  ===
  --- en/boot-installer/powerpc.xml   (Revision 69729)
  +++ en/boot-installer/powerpc.xml   (Arbeitskopie)
  @@ -283,3 +283,41 @@
   
   /para
 /sect2
  +
  +  sect2 arch=ppc64el titleBooting a ppc64el machine/title
  +para
  +
  +How to boot a ppc64el machine:
  +
  +/para
  +
  +  sect3 titlePetitboot/title
  +para
  +
  +Petitboot is a platform independent bootloader based on the Linux kexec.
  +Petitboot supports loading kernel, initrd and device tree files from 
  +any Linux mountable filesystem, plus can load files from the network 
  +using the FTP, SFTP, TFTP, NFS, HTTP and HTTPS protocols. Petitboot can
  +boot any operating system that includes kexec boot support.
  +
  +/parapara
  +
  +Petitboot looks for bootloader configuration files on mountable devices
  +in the system, and can also be configured to use boot information from a
  +DHCP server.
  +
  +/para
  +  /sect3
  +
  +!-- comment this out for now, since there is no content
  +  sect3 titleBoot parameters/title
  +para
  +Boot parameters for ppc64el
  +
  +FIXME: add some useful content here
  +
  +/para
  +  /sect3
  +--
  +
  +  /sect2
 
 Since petitboot runs inside a running linux kernel, that only shifts the
 problem of booting that linux kernel :)

Petitboot is the default bootloader on this machine when configured to
run Linux. It's the interface the user see when powering up the machine.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150412200844.go4...@aurel32.net

Re: Help with the arm64 and ppc64el installation-guides needed

[Holger Wansing]

Hi,

Holger Wansing li...@wansing-online.de wrote:
 All that contained in attached patch for review.

I forgot to mention the arch specific variables in
build/arch-options/ppc64el.
There are currently set:


# Options below are assembled into one variable 'condition'
# in the build scripts
fdisk=mac-fdisk.txt;cfdisk.txt
network=supports-tftp;supports-bootp;supports-nfsroot
boot=supports-floppy-boot;bootable-disk
frontend=newt;gtk
other=supports-wireless;supports-pcmcia;supports-serial-console
smp=supports-smp-sometimes
goodies=supports-lang-chooser
status=not-checked


Probably some of them are not up-to-date:
supports-floppy-boot - I think that arch has no floppy support
supports-wireless - is there wireless hardware available?
supports-smp-sometimes - that generation of cpu will most likely
 fully support smp, right?
... maybe some more ...




Can someone on debian-powerpc give info on that?


Holger


-- 

Created with Sylpheed 3.2.0 under
D E B I A N   L I N U X   7 . 0   W H E E Z Y !

Registered Linux User #311290 - https://linuxcounter.net/



-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150411202249.d840b1199c45e272a4316...@wansing-online.de

Re: Help with the arm64 and ppc64el installation-guides needed

[Holger Wansing]

Hi,

Holger Wansing li...@wansing-online.de wrote:
 Hi,
 
 Holger Wansing li...@wansing-online.de wrote:
  All that contained in attached patch for review.
 
 I forgot to mention the arch specific variables in
 build/arch-options/ppc64el.

And: is there support for the graphical installer?
As far as I can see, the images do not contain the graphical
installer.
So that should be set to NO.


Holger

-- 

Created with Sylpheed 3.2.0 under
D E B I A N   L I N U X   7 . 0   W H E E Z Y !

Registered Linux User #311290 - https://linuxcounter.net/



-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150411212037.b8353ac0ac99bd8c3508b...@wansing-online.de

Re: Help with the arm64 and ppc64el installation-guides needed

[Holger Wansing]

Hi,

Samuel Thibault sthiba...@debian.org wrote:
 Breno Leitao, le Fri 10 Apr 2015 17:44:01 -0300, a écrit :
  It is still on my github repository. Can you import it?
 
 Uh. I requested this very kind of information in september and
 november, why wasn't this work (done in december) ever submitted
 before?  We can integrate it in the installation manual, but it will
 most probably not get translated for the release...

Yeah, it's a shame this has not been presented earlier!

 I'll however be unable to integrate things like blablabla (sic)...

The blablabla is indeed only a placeholder which gets removed in a later
commit.
If noone objects, I could create one single patch out of that for 
a review here.


Holger

-- 

Created with Sylpheed 3.2.0 under
D E B I A N   L I N U X   7 . 0   W H E E Z Y !

Registered Linux User #311290 - https://linuxcounter.net/



--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150411100126.b62e9543f4975d4a861b3...@wansing-online.de

Re: Help with the arm64 and ppc64el installation-guides needed

[Holger Wansing]

Hi,

Holger Wansing li...@wansing-online.de wrote:
 Samuel Thibault sthiba...@debian.org wrote:
  Breno Leitao, le Fri 10 Apr 2015 17:44:01 -0300, a écrit :
   It is still on my github repository. Can you import it?
  
  Uh. I requested this very kind of information in september and
  november, why wasn't this work (done in december) ever submitted
  before?  We can integrate it in the installation manual, but it will
  most probably not get translated for the release...
 
 Yeah, it's a shame this has not been presented earlier!
 
  I'll however be unable to integrate things like blablabla (sic)...
 
 The blablabla is indeed only a placeholder which gets removed in a later
 commit.

Sorry, I did not noticed there were several blablabla, only saw the first
one in preparing. So there is still some content missing indeed, as Samuel
mentioned! But we have several empty sections for other archs or
d-i modules too...

 If noone objects, I could create one single patch out of that for 
 a review here.

So here we go.

I have merged Brenos changings in a local tree, and additionally to that:

in build/entities/common.ent there was the name of the architecture
missing. So what's the exact pronunciation of that arch?
(for powerpc we have PowerPC for example)
Is there some special form, or simply ppc64el?
In Supported hardware Breno has Power Systems as arch name. ???
The ports page on https://www.debian.org/ports/ lists
https://wiki.debian.org/ppc64el/ as basic info page for the
ppc64el port, and there is no mention of Power Systems...
Also, in Instructions for Netboot installation under preparing
there is the term PowerLinux machine. 
This all should be harmonized to one term.

commented out Boot parameters for ppc64el in Booting the installer,
since there is no content

commented out Updating PowerVM hypervisor in Pre-Installation 
Hardware and Operating System Setup, since there is no content

some small fixes (file name.img - file_name.img)

Add some blank lines for document structure.

Convert list in Supported Hardware - Machines into
itemizedlist.



All that contained in attached patch for review.
The manual builds fine with it.


Holger

-- 

Created with Sylpheed 3.2.0 under
D E B I A N   L I N U X   7 . 0   W H E E Z Y !

Registered Linux User #311290 - https://linuxcounter.net/

Index: build/arch-options/ppc64el
===
--- build/arch-options/ppc64el	(Revision 69729)
+++ build/arch-options/ppc64el	(Arbeitskopie)
@@ -2,9 +2,9 @@
 # the 'ppc64el' architecture
 # It is sourced by the build scripts
 
-archspec=powerpc;not-s390;not-x86
-arch_listname=powerpc
-arch_porturl=powerpc
+archspec=ppc64el;not-s390;not-x86
+arch_listname=ppc64el
+arch_porturl=ppc64el
 # TODO: update
 # This is coming from the lowmem package
 minimum_memory=32
Index: build/templates/docstruct.ent
===
--- build/templates/docstruct.ent	(Revision 69729)
+++ build/templates/docstruct.ent	(Arbeitskopie)
@@ -136,6 +136,7 @@
   !ENTITY module-s390-zipl-installer.xml SYSTEM ##SRCPATH##/using-d-i/modules/s390/zipl-installer.xml
   !ENTITY module-powerpc-yaboot-installer.xml  SYSTEM ##SRCPATH##/using-d-i/modules/powerpc/yaboot-installer.xml
   !ENTITY module-powerpc-quik-installer.xml  SYSTEM ##SRCPATH##/using-d-i/modules/powerpc/quik-installer.xml
+  !ENTITY module-powerpc-grub-installer.xml SYSTEM ##SRCPATH##/using-d-i/modules/powerpc/grub-installer.xml
   !ENTITY module-sparc-silo-installer.xmlSYSTEM ##SRCPATH##/using-d-i/modules/sparc/silo-installer.xml
   !ENTITY module-arm-flash-kernel-installer.xmlSYSTEM ##SRCPATH##/using-d-i/modules/arm/flash-kernel-installer.xml
   !ENTITY module-nobootloader.xml   SYSTEM ##SRCPATH##/using-d-i/modules/nobootloader.xml
Index: build/entities/urls.ent
===
--- build/entities/urls.ent	(Revision 69729)
+++ build/entities/urls.ent	(Arbeitskopie)
@@ -311,6 +311,8 @@
 !ENTITY url-powerpc-bootx
http://penguinppc.org/projects/bootx/;
 
+!ENTITY url-ibm-powerkvm
+ https://www.ibm.com/developerworks/linux/tutorials/l-ibm-powerkvm-system-bring-up/;
 
 !-- ** mips links --
 
Index: build/entities/common.ent
===
--- build/entities/common.ent	(Revision 69729)
+++ build/entities/common.ent	(Arbeitskopie)
@@ -24,7 +24,7 @@
 
 !-- proper nouns for architectures --
 !ENTITY arch-title
-  phrase arch='any-amd64'64-bit PC/phrasephrase arch='arm'ARM/phrasephrase arch='hppa'PA-RISC/phrasephrase arch='any-i386'32-bit PC/phrasephrase 

Re: Help with the arm64 and ppc64el installation-guides needed

[Ben Hutchings]

On Sat, 2015-04-11 at 17:13 +0200, Holger Wansing wrote:
 Hi,
 
 Holger Wansing li...@wansing-online.de wrote:
  Samuel Thibault sthiba...@debian.org wrote:
   Breno Leitao, le Fri 10 Apr 2015 17:44:01 -0300, a écrit :
It is still on my github repository. Can you import it?
   
   Uh. I requested this very kind of information in september and
   november, why wasn't this work (done in december) ever submitted
   before?  We can integrate it in the installation manual, but it will
   most probably not get translated for the release...
  
  Yeah, it's a shame this has not been presented earlier!
  
   I'll however be unable to integrate things like blablabla (sic)...
  
  The blablabla is indeed only a placeholder which gets removed in a later
  commit.
 
 Sorry, I did not noticed there were several blablabla, only saw the first
 one in preparing. So there is still some content missing indeed, as Samuel
 mentioned! But we have several empty sections for other archs or
 d-i modules too...
 
  If noone objects, I could create one single patch out of that for 
  a review here.
 
 So here we go.
 
 I have merged Brenos changings in a local tree, and additionally to that:
 
   in build/entities/common.ent there was the name of the architecture
   missing. So what's the exact pronunciation of that arch?
   (for powerpc we have PowerPC for example)
   Is there some special form, or simply ppc64el?
   In Supported hardware Breno has Power Systems as arch name. ???
   The ports page on https://www.debian.org/ports/ lists
   https://wiki.debian.org/ppc64el/ as basic info page for the
   ppc64el port, and there is no mention of Power Systems...
   Also, in Instructions for Netboot installation under preparing
   there is the term PowerLinux machine. 
   This all should be harmonized to one term.
[...]

Based on
http://openpowerfoundation.org/technical/technical-resources/technical-specifications/
 I think it's 'PowerPC 64-bit little-endian', or 'PowerISA little-endian'.

However, comparing with the way we've named other architectures, '64-bit
PowerPC (little-endian)' would be more consistent.

Ben.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source


signature.asc
Description: This is a digitally signed message part

Re: Help with the arm64 and ppc64el installation-guides needed

[Ben Hutchings]

On Sat, 2015-04-11 at 20:22 +0200, Holger Wansing wrote:
 Hi,
 
 Holger Wansing li...@wansing-online.de wrote:
  All that contained in attached patch for review.
 
 I forgot to mention the arch specific variables in
 build/arch-options/ppc64el.
 There are currently set:
 
 
   # Options below are assembled into one variable 'condition'
   # in the build scripts
   fdisk=mac-fdisk.txt;cfdisk.txt
   network=supports-tftp;supports-bootp;supports-nfsroot
   boot=supports-floppy-boot;bootable-disk
   frontend=newt;gtk
   other=supports-wireless;supports-pcmcia;supports-serial-console
   smp=supports-smp-sometimes
   goodies=supports-lang-chooser
   status=not-checked
 
 
 Probably some of them are not up-to-date:
 supports-floppy-boot - I think that arch has no floppy support
 supports-wireless - is there wireless hardware available?

Current hardware is mostly datacentre type stuff where wireless
networking is not likely to be used.

In any case, none of the PowerPC architectures seem to have useful
wireless drivers in the installer (only PCMCIA wireless drivers, for
some reason).

 supports-smp-sometimes - that generation of cpu will most likely
  fully support smp, right?
[...]

Yes.

Ben.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source


signature.asc
Description: This is a digitally signed message part

Re: Help with the arm64 and ppc64el installation-guides needed

[Breno Leitao]

hi Karsten,

On 04/09/2015 01:13 PM, Karsten Merker wrote: Hello everybody,

 the release date for Jessie is near, but the installation-guide
 does not seem to contain any arm64/ppc64el-specific information
 yet.
We have created this installation guide, but unfortunatelly it was not 
integrated yet.

It is still on my github repository. Can you import it?

https://github.com/leitao/installation-guide


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55283611.7000...@br.ibm.com

Re: Help with the arm64 and ppc64el installation-guides needed

[Sandeep G.R]

Hi Karsten,

I have a sid PPC64 from http://ftp.de.debian.org/debian-ports running on
Freescale Powerpc. Is their PPC64(Big-Endian) for Jessie similarly?

On Fri, Apr 10, 2015 at 2:44 PM, Breno Leitao bren...@br.ibm.com wrote:

 hi Karsten,

 On 04/09/2015 01:13 PM, Karsten Merker wrote: Hello everybody,
 
  the release date for Jessie is near, but the installation-guide
  does not seem to contain any arm64/ppc64el-specific information
  yet.
 We have created this installation guide, but unfortunatelly it was not
 integrated yet.

 It is still on my github repository. Can you import it?

 https://github.com/leitao/installation-guide


 --
 To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive: https://lists.debian.org/55283611.7000...@br.ibm.com




-- 
*Thanks  Regards,*
*Sandeep G R*

Re: Help with the arm64 and ppc64el installation-guides needed

[Samuel Thibault]

Hello,

Breno Leitao, le Fri 10 Apr 2015 17:44:01 -0300, a écrit :
 On 04/09/2015 01:13 PM, Karsten Merker wrote: Hello everybody,
  the release date for Jessie is near, but the installation-guide
  does not seem to contain any arm64/ppc64el-specific information
  yet.
 We have created this installation guide, but unfortunatelly it was not 
 integrated yet.
 
 It is still on my github repository. Can you import it?

Uh. I requested this very kind of information in september and
november, why wasn't this work (done in december) ever submitted
before?  We can integrate it in the installation manual, but it will
most probably not get translated for the release...

I'll however be unable to integrate things like blablabla (sic)...

Samuel


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150410222458.gd4...@type.youpi.perso.aquilenet.fr

Re: Help with the arm64 and ppc64el installation-guides needed

[Thadeu Lima de Souza Cascardo]

On Sat, Apr 11, 2015 at 12:24:58AM +0200, Samuel Thibault wrote:
 Hello,
 
 Breno Leitao, le Fri 10 Apr 2015 17:44:01 -0300, a écrit :
  On 04/09/2015 01:13 PM, Karsten Merker wrote: Hello everybody,
   the release date for Jessie is near, but the installation-guide
   does not seem to contain any arm64/ppc64el-specific information
   yet.
  We have created this installation guide, but unfortunatelly it was not 
  integrated yet.
  
  It is still on my github repository. Can you import it?
 
 Uh. I requested this very kind of information in september and
 november, why wasn't this work (done in december) ever submitted
 before?  We can integrate it in the installation manual, but it will
 most probably not get translated for the release...
 
 I'll however be unable to integrate things like blablabla (sic)...
 
 Samuel
 

Also, most of the content is oriented towards updating the machine
software itself, not Debian. How does one install Debian on bare-metal,
using petitboot? How does one install Debian as a KVM guest with SLOF?
How about Debian on a LPAR on PowerVM? Which systems would support it in
that mode?

Cascardo.


signature.asc
Description: Digital signature

Re: Help with powerbutton handling

[Dario Piantanida]

A little step forward.

There's a buttond_service.pyc that seems to be able to handle the button
pressing:

class ButtondService(persistent_service.PersistentService):
 Buttond Service Class 
[...]
def _worker(self):

_worker method (override from superclass)

input = self.__button.get_data()
event_struct_size = struct.calcsize(FORMAT_INPUT_EVENT)
event_num = len(input) / event_struct_size
event_queue = Queue.Queue()
[...]
if button[BTN_ACTION_TYPE] == 'internal':
try:
action_func =
self.__action_functions[button[BTN_ACTION_NAME]]

But... I can't find when that _worker method will get called.
I don't see where this service is somehow registered to receive button
events.

Can anybody help?


On Mon, Oct 6, 2014 at 10:18 AM, Dario Piantanida 
dario.piantan...@gmail.com wrote:

 Hello, I have an LG NAS based on Debian 6, armel arch.
 I have root access on it.

 I recently broke a couple of things on it, but now it's almost back.
 I found it is highly customized about services to start and other system
 handling.

 The last thing I haven't been able to restore is the handling of the
 powerbutton: before me touching things, I could turn it off keeping it
 pressed for 2/3 seconds; a longer press would turn it off immediately.

 Now it loose the 2/3 seconds reaction, I must log in and shutdown manually.

 I found some ACPI scripts and services, but they all start with a testing
 of an env variable micom that it must not be set to emul, otherwise
 they exit instantly.

 As micom is not emul, they are useless.
 I even tried starting acpid -f from command line, but it says it lacks
 some input file somewhere, so the handling must be something custom again.

 The whole NAS platform is started from a bunch of python scripts and I
 found they do list the button reactions, listing shutdown with code 45,
 but I can't understand how it gets called.

 This is the action defined:
 @classmethod
 def action_shutdown(cls):
  action shutdown - evnet code: 45 
 buzzer.Buzzer().enable()
 initd.Initd().shutdown()

 If I search for action_shutdown in the scripts, I find:

 class ButtondService(persistent_service.PersistentService):
  Buttond Service Class 
 _sleep_duration = 0
 __button = None
 __action_functions = {'IP_DHCP':
 button_action.ButtonAction.action_ip_dhcp,
 [...]
  'SHUTDOWN': button_action.ButtonAction.action_shutdown,
 [...]
 __conf_table = []
 __conf_table_file = '/etc/nas/button.conf'

 /etc/nas/button.conf is a list of buttons and codes.

 Searching for SHUTDOWN, I find it is used in here:
 @classmethod
 def _shutdown(cls, args):
  Stop all service and umount volumes under platformd

 This function is mapped in an array:
 class SystemService(EphemeralService):
  System Service Class 
 _locked = False
 _actions = {'get_greeting': ['_get_greeting', ()],
 [...]
  'shutdown': ['_shutdown', ()],

 I then lose traces of the calls and I'm not sure what really should
 triggers these calls.

 Can anybody suggest any string I could search for to understand what
 system event would trigger a powerbutton press reaction?

 Thank you!

Re: Help with powerbutton handling

[Dominique Dumont]

On Monday 06 October 2014 10:18:01 Dario Piantanida wrote:
 The last thing I haven't been able to restore is the handling of the 
 powerbutton: before me touching things, I could turn it off keeping it 
 pressed for 2/3 seconds; a longer press would turn it off immediately. 

Make sure that acpi-support-base package is installed

HTH

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/3252092.Trg8V6vHi5@ylum

Re: Help with powerbutton handling

[Dario Piantanida]

I checked current system status with an old backup and I would say the acpi
packages are as before, when it worked...

As I said, it is very custom and I'd prefer to stick with their
implementations, if I get to understand it.

On Mon, Oct 6, 2014 at 10:59 AM, Dominique Dumont dominique.dum...@hp.com
wrote:

 On Monday 06 October 2014 10:18:01 Dario Piantanida wrote:
  The last thing I haven't been able to restore is the handling of the
  powerbutton: before me touching things, I could turn it off keeping it
  pressed for 2/3 seconds; a longer press would turn it off immediately.

 Make sure that acpi-support-base package is installed

 HTH

 --
  https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
 http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org


 --
 To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive: https://lists.debian.org/3252092.Trg8V6vHi5@ylum

Re: Help with powerbutton handling

[Paul Wise]

On Mon, Oct 6, 2014 at 4:18 PM, Dario Piantanida wrote:

 Hello, I have an LG NAS based on Debian 6, armel arch.

BTW, Debian 6 is EOL and is no longer security supported at all on
armel (i386/amd64 have LTS support). I strongly suggest you upgrade to
Debian 7 (wheezy).

 I found some ACPI scripts and services

Are you sure this is ACPI based? I thought that systems of this
vintage would not use ACPI as it is only now starting to be introduced
with devices running UEFI boot firmware.

For a device like this with a custom Debian install not based on one
from the Debian installer/debootstrap, I would strongly suggest to
have full-system backups, including all binaries and configuration
files or at least a backup of the files that are different to those
from a standard install.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6hldnm0m4gbf+ub3a+qxwy_qvrt2fnvcymrq0y-hva...@mail.gmail.com

Re: Help with powerbutton handling

[Lennart Sorensen]

On Tue, Oct 07, 2014 at 09:21:02AM +0800, Paul Wise wrote:
 BTW, Debian 6 is EOL and is no longer security supported at all on
 armel (i386/amd64 have LTS support). I strongly suggest you upgrade to
 Debian 7 (wheezy).
 
 Are you sure this is ACPI based? I thought that systems of this
 vintage would not use ACPI as it is only now starting to be introduced
 with devices running UEFI boot firmware.

ACPI is OLD.  It came out in 1996.  They are on version 5 as of 2011.
UEFI has taken over maintaining ACPI these days.

Of course on arm, ACPI is new for 64bit arm and has never been used on
older arm designs that I have ever heard of.

 For a device like this with a custom Debian install not based on one
 from the Debian installer/debootstrap, I would strongly suggest to
 have full-system backups, including all binaries and configuration
 files or at least a backup of the files that are different to those
 from a standard install.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141007022132.gz4...@csclub.uwaterloo.ca

Re: Help needed with qtcreator FTBFS on arm*

[Lisandro Damián Nicanor Pérez Meyer]

I have just noted that qtcreator built on armel and is currently building on 
armhf (let's hope it now builds!)

To whoever fixed it, thanks *a lot*. If someone could tell me which was the 
problem, even better.

Thanks, Lisandro.

-- 
8: Si un archivo ha pasado a la Papelera de Reciclaje
* Ud tiene una carpeta llamada Papelera de Reciclaje
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: Help needed with qtcreator FTBFS on arm*

[Lisandro Damián Nicanor Pérez Meyer]

On Saturday 21 June 2014 18:29:43 Dmitry Shachnev wrote:
 On Sat, Jun 21, 2014 at 6:15 PM, Lisandro Damián Nicanor Pérez Meyer
 
 perezme...@gmail.com wrote:
  I've tried to build it twice on an armhf porterbox and Dmitry Schanev
  tried on an armel qemu VM. In my case the porterbox would simply hang
  before reaching where the buildd gets, and I think the VM build also
  failed earlier.
 FWIW my armhf build segfaulted, but armel build succeeded:
 
 http://95.85.27.130/builds/qtcreator_3.1.1+dfsg-1_armhf.build
 http://95.85.27.130/builds/qtcreator_3.1.1+dfsg-1_armel.build

Recently qtcreator failed much like this on mips. It turned out to be a memory 
issue and rebuilding on a buildd with more ram+swap did the trick.

The build logs for qtcreator on arm* do not always fail in the same way and/or 
in the same point, plus Dmitry managed to get it to build without issues with 
an armel VM. So maybe it's also a memory issue.

Which armel and armhf buildds have the most amount of ram+swap? I would like 
to see if the source tried to build there and else give it a try.

Thanks in advance, Lisandro.

-- 
Los errores ortográficos y de redacción fueron insertados con la única
intención de testear sus conocimientos de la lengua castellana.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: Help needed with qtcreator FTBFS on arm*

[Dmitry Shachnev]

On Sat, Jun 21, 2014 at 6:15 PM, Lisandro Damián Nicanor Pérez Meyer
perezme...@gmail.com wrote:
 I've tried to build it twice on an armhf porterbox and Dmitry Schanev tried on
 an armel qemu VM. In my case the porterbox would simply hang before reaching
 where the buildd gets, and I think the VM build also failed earlier.

FWIW my armhf build segfaulted, but armel build succeeded:

http://95.85.27.130/builds/qtcreator_3.1.1+dfsg-1_armhf.build
http://95.85.27.130/builds/qtcreator_3.1.1+dfsg-1_armel.build

Both were done in qemu.

--
Dmitry Shachnev


--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKimPHUsAAsRH5Tyb=ql+p2+met1dbr+gltbvqqczafxrac...@mail.gmail.com

Re: Help needed with qtcreator FTBFS on arm*

[Timo Jyrinki]

2014-06-21 17:15 GMT+03:00 Lisandro Damián Nicanor Pérez Meyer
perezme...@gmail.com:
 Hi ARM porters! I'm writing you because we currently have qtcreator FTBFS only
 on ARM* [0] and we can't figure out what's the problem.

Ubuntu has qtcreator 3.1.1 built for armhf. I think the main
difference is that Ubuntu has been using g++-4.7 on armhf for
qtcreator, because of past problems with qtcreator built against Qt 5
on armhf. That's a quite big hammer though, so a better solution or a
smaller testcase to file a bug with would be of course good.

-Timo


--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cajtffxnriynoczpz9trsmvg-rbjjvgakbq0w_ws94qzwmnu...@mail.gmail.com

Re: Help with Wheezy CD testing on Saturday

[Peter Chubb]

 Émeric == Émeric Maschino emeric.masch...@gmail.com writes:


Émeric Just to let you know that I've successfully installed Wheezy
Émeric using the netinst CD on a spare HDD, using default parameters
Émeric (using entire HDD and one single partition as partition
Émeric scheme) except for localization of course.

I've been trying to install using the XFCE CD on a zx6000.  The boot
rom doesn't recognise the CD as being bootable.The netinst CD does
work.


--
Dr Peter Chubb  peter.chubb AT nicta.com.au
http://www.ssrg.nicta.com.au  Software Systems Research Group/NICTA


--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/84ehcxhtmj.wl%pe...@chubb.wattle.id.au