Re: Debian 7.0 on Dreamplug basic installation and booting system external sd card

2013-10-29 Thread Stanley Pilton
I should mention that the storage scheme I chose was use whole disk
and use lvm, which resulted in a partition for /boot and a VG with an
LV for /

Is this expected to work?


-- 
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/CAGtFLY67H=tafirsrds8k6-v-zcxu4qfk4fdaoitrmkkmpc...@mail.gmail.com



Re: Debian on QNAP 419P II

2013-10-29 Thread Björn Wetterbom
Just wanted to report a successful install. Compared to my old TS209 the
throughput increased vastly. I have a gigabit network and with the TS209 I
got about 140 Mbit/s (RAID1 with two disks). Now I get about 700 Mbit/s
(RAID6 with four disks). Tests were performed with iperf against a very
capable Dell laptop with SSD, Win 7 and Cygwin. Just for kicks I'm going to
try a RAID0 with four disks to see if I can push that number even higher.

BTW Martin, on http://cyrius.com/debian/kirkwood/qnap/ts-41x/uboot/ it's
not enough to set 'ipaddr'. You also have to set 'eth1addr'. They have to
be both set, I don't know why. I ended up using 'fatload' instead (inspired
by http://cyrius.com/debian/kirkwood/sheevaplug/install/), which is easier
and faster IMO.

/Björn


On Thu, Oct 17, 2013 at 3:26 PM, Martin Michlmayr t...@cyrius.com wrote:

 * Björn Wetterbom bj...@wetterbom.se [2013-10-17 15:16]:
  How right you are. Well, Martin is a thorough guy, so I'm sure it's not
  there by accident, i.e. it's supported.

 Obviously not thorough enough. ;)  I'll add it to the index and install
 pages.

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



Re: Bug#727886: gtk2-engines-wonderland: update config.{sub,guess} for the AArch64 port

2013-10-29 Thread Dererk
On 27/10/13 13:00, Matthias Klose wrote:
 Package: src:gtk2-engines-wonderland
 Version: 1.0-8
 Severity: normal
 User: debian-arm@lists.debian.org
 Usertags: arm64

 The package fails to build on arm64 (aarch64-linux-gnu), because the
 config.{guess,sub} files are out of date, and are not updated during
 the build.  If possible, please do not update these files directly,
 but build-depend on autotools-dev instead, and use the tools provided
 by autotools-dev to update these files.

Hi there.

Thanks for filling this bug report and for the details, Matthias.

I was hoping I could test a candidate fix package about this, but seems
no buildd (or at least DSA-managed boxes as for[1]) is available on such
architecture yet.
Is that right?



Cheers,

Dererk

1. https://db.debian.org/machines.cgi

-- 
BOFH excuse #306:
CPU-angle has to be adjusted because of vibrations coming from the nearby road




signature.asc
Description: OpenPGP digital signature


Re: Bug#727886: gtk2-engines-wonderland: update config.{sub,guess} for the AArch64 port

2013-10-29 Thread Wookey
+++ Dererk [2013-10-29 10:52 -0300]:
 On 27/10/13 13:00, Matthias Klose wrote:
  Package: src:gtk2-engines-wonderland
  Version: 1.0-8
  Severity: normal
  User: debian-arm@lists.debian.org
  Usertags: arm64
 
  The package fails to build on arm64 (aarch64-linux-gnu), because the
  config.{guess,sub} files are out of date, and are not updated during
  the build.  If possible, please do not update these files directly,
  but build-depend on autotools-dev instead, and use the tools provided
  by autotools-dev to update these files.
 
 Hi there.
 
 Thanks for filling this bug report and for the details, Matthias.
 
 I was hoping I could test a candidate fix package about this, but seems
 no buildd (or at least DSA-managed boxes as for[1]) is available on such
 architecture yet.
 Is that right?

It is. Porters don't even have hardware yet - it's still exceedingly rare. 
We are currently trying to get access to some. Anyone can run stuff in a model:
https://wiki.debian.org/Arm64Port#Pre-built_Rootfs but it's slow and you 
currently only get ubuntu, not debian, and there is a bit off faff involved 
with turning the ubuntu-core tarball there into a working image you can boot..
I have some scripts and images I should upload for that.

If you've made the changes in the bug and it still works on existing arches 
then please upload it. It'll get tested on arm64 as soon as that becomes 
practical 
and makes the bootstrap easier.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, 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: http://lists.debian.org/20131029142626.gb6...@stoneboat.aleph1.co.uk



Re: Bug#727886: gtk2-engines-wonderland: update config.{sub,guess} for the AArch64 port

2013-10-29 Thread Dererk
On 29/10/13 11:26, Wookey wrote:
 +++ Dererk [2013-10-29 10:52 -0300]:
 On 27/10/13 13:00, Matthias Klose wrote:
 Package: src:gtk2-engines-wonderland
 Version: 1.0-8
 Severity: normal
 User: debian-arm@lists.debian.org
 Usertags: arm64

 The package fails to build on arm64 (aarch64-linux-gnu), because the
 config.{guess,sub} files are out of date, and are not updated during
 the build.  If possible, please do not update these files directly,
 but build-depend on autotools-dev instead, and use the tools provided
 by autotools-dev to update these files.

 Hi there.

 Thanks for filling this bug report and for the details, Matthias.

 I was hoping I could test a candidate fix package about this, but seems
 no buildd (or at least DSA-managed boxes as for[1]) is available on such
 architecture yet.
 Is that right?
 It is. Porters don't even have hardware yet - it's still exceedingly rare. 
 We are currently trying to get access to some. Anyone can run stuff in a 
 model:
 https://wiki.debian.org/Arm64Port#Pre-built_Rootfs but it's slow and you 
 currently only get ubuntu, not debian, and there is a bit off faff involved 
 with turning the ubuntu-core tarball there into a working image you can boot..
 I have some scripts and images I should upload for that.

 If you've made the changes in the bug and it still works on existing arches 
 then please upload it. It'll get tested on arm64 as soon as that becomes 
 practical 
 and makes the bootstrap easier.

 Wookey
Thanks Wookey!

You have been extremely helpful on this matter.



Cheers,

Dererk

-- 
BOFH excuse #306:
CPU-angle has to be adjusted because of vibrations coming from the nearby road




signature.asc
Description: OpenPGP digital signature


Re: Bits from the Release Team (Jessie freeze info)

2013-10-29 Thread Ian Jackson
Niels Thykier writes (Bits from the Release Team (Jessie freeze info)):
 Results of porter roll-call
 ===
...
 Summary table:
 Arch   || DDs || NMs/DMs || Other || Total
 - ---++-++-++---++--
 armel  ||  5  ||   0 || 2 ||7
 armhf  ||  6  ||   1 || 2 ||9
 hurd-i386  ||  5  ||   0 || 3 ||8
 ia64   || *0* ||   0 || 3 ||3
 kfreebsd-amd64 ||  5  ||   0 || 2 ||6
 kfreebsd-i386  ||  5  ||   0 || 2 ||6
 mips   ||  2  ||   0 || 1 ||3
 mipsel ||  2  ||   0 || 1 ||3
 powerpc[1] || (1) ||   0 || 2 ||   2.5?
 s390x  ||  1  ||   0 || 1 ||2
 sparc  ||  1  ||   0 || 0 ||1
...
 Based on the number of porters, we are considering changing the
 current requirements of 5 DDs to better reflect the reality of the
 situation.  We will follow up in a future bits on the changes.

Thanks.

I think it is disappointing to find that we may be dropping
architectures where a significant amount of effort is available,
simply because the volunteers don't have enough status - specifically,
because of a lack of DDs.

I'm keen that Debian should continue to support a wide range of
architectures.  Would it help if I, as a DD, volunteered to sponsor
porter uploads for any architecture ?  That is I guess I'm
volunteering to become a new kind of person - a non-port-specific
porter sponsor.

Obviously I will review the debdiff etc.  I'm an experienced C
programmer with some background in C language lawyering and
portability stuff, so I should usually be able to do a decent review
of a patch even on an unfamiliar architecture.

In fact, regardless of what the release team decide for the policy, I
would be happy to sponsor porter uploads.  Please just email me.

Ian.


-- 
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/21103.52917.876297.985...@chiark.greenend.org.uk



Re: Bits from the Release Team (Jessie freeze info)

2013-10-29 Thread Niels Thykier
On 2013-10-29 16:05, Ian Jackson wrote:
 Niels Thykier writes (Bits from the Release Team (Jessie freeze info)):
 Results of porter roll-call
 ===
 ...
 Summary table:
 Arch   || DDs || NMs/DMs || Other || Total
 - ---++-++-++---++--
 armel  ||  5  ||   0 || 2 ||7
 armhf  ||  6  ||   1 || 2 ||9
 hurd-i386  ||  5  ||   0 || 3 ||8
 ia64   || *0* ||   0 || 3 ||3
 kfreebsd-amd64 ||  5  ||   0 || 2 ||6
 kfreebsd-i386  ||  5  ||   0 || 2 ||6
 mips   ||  2  ||   0 || 1 ||3
 mipsel ||  2  ||   0 || 1 ||3
 powerpc[1] || (1) ||   0 || 2 ||   2.5?
 s390x  ||  1  ||   0 || 1 ||2
 sparc  ||  1  ||   0 || 0 ||1
 ...
 Based on the number of porters, we are considering changing the
 current requirements of 5 DDs to better reflect the reality of the
 situation.  We will follow up in a future bits on the changes.
 
 Thanks.
 

You are welcome. :)

 I think it is disappointing to find that we may be dropping
 architectures where a significant amount of effort is available,
 simply because the volunteers don't have enough status - specifically,
 because of a lack of DDs.
 

As mentioned we are debating whether the 5 DDs requirement still makes
sense.  Would you say that we should abolish the requirement for DD
porters completely?  I.e. Even if there are no (soon to be) DDs, we
should consider the porter requirements fulfilled as long as they are
enough active porters behind the port[0]?

 I'm keen that Debian should continue to support a wide range of
 architectures.  Would it help if I, as a DD, volunteered to sponsor
 porter uploads for any architecture ?  That is I guess I'm
 volunteering to become a new kind of person - a non-port-specific
 porter sponsor.
 

I suppose that could help ports without a DD if we allowed such to be in
testing.  However, it is my understanding that our main issue with ports
often is that they are not actively maintained (or appears to lack
active maintenance).
  As an example I remember having received several complains from e.g.
the GCC maintainers in regards to the state of gcc on various ports[1].
 Here I would suspect a patch would be sufficient without needing to
actually NMU gcc to get the fix in.
  There are also stuff like the port concerns from DSA that attention.

 Obviously I will review the debdiff etc.  I'm an experienced C
 programmer with some background in C language lawyering and
 portability stuff, so I should usually be able to do a decent review
 of a patch even on an unfamiliar architecture.
 
 In fact, regardless of what the release team decide for the policy, I
 would be happy to sponsor porter uploads.  Please just email me.
 
 Ian.
 
 

:)

~Niels

[0] Leaving the definition of active porter vaguely defined for now.

[1] Obviously, I haven't been keeping track of them so I had to ask for
a reminder.

https://lists.debian.org/debian-release/2013/10/msg00710.html



-- 
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/526fdfe3.7060...@thykier.net



Re: Bits from the Release Team (Jessie freeze info)

2013-10-29 Thread Ian Jackson
Niels Thykier writes (Re: Bits from the Release Team (Jessie freeze info)):
 On 2013-10-29 16:05, Ian Jackson wrote:
  I'm keen that Debian should continue to support a wide range of
  architectures.  Would it help if I, as a DD, volunteered to sponsor
  porter uploads for any architecture ?  That is I guess I'm
  volunteering to become a new kind of person - a non-port-specific
  porter sponsor.
...
 I suppose that could help ports without a DD if we allowed such to be in
 testing.

Indeed.

  However, it is my understanding that our main issue with ports
 often is that they are not actively maintained (or appears to lack
 active maintenance).

Right.

 As mentioned we are debating whether the 5 DDs requirement still makes
 sense.  Would you say that we should abolish the requirement for DD
 porters completely?  I.e. Even if there are no (soon to be) DDs, we
 should consider the porter requirements fulfilled as long as they are
 enough active porters behind the port[0]?

I don't have a good feel for the answer to that question.  

It's just that if it is the case that a problem with ports is the lack
of specifically DDs, rather than porter effort in general, then
sponsorship is an obvious way to solve that problem.

If you feel that that's not really the main problem then a criterion
which counts porters of any status would be better.

(Mind you, I have my doubts about a process which counts people
promising to do work - it sets up some rather unfortunate incentives.
I guess it's easier to judge and more prospective than a process which
attempts to gauge whether the work has been done well enough.)

   As an example I remember having received several complains from
 e.g.  the GCC maintainers in regards to the state of gcc on various
 ports[1].  Here I would suspect a patch would be sufficient without
 needing to actually NMU gcc to get the fix in.  There are also stuff
 like the port concerns from DSA that attention.

Right.

Thanks,
Ian.


-- 
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/21103.59120.410686.914...@chiark.greenend.org.uk



Re: Dropping valgrind from armel?

2013-10-29 Thread Alessandro Ghedini
On lun, ott 28, 2013 at 09:36:22 -0400, Jerry Stuckle wrote:
 On 10/28/2013 6:02 PM, Alessandro Ghedini wrote:
 On Thu, Oct 24, 2013 at 08:24:28PM +0200, Alessandro Ghedini wrote:
 Hi all,
 
 long story short, a couple years ago armel builds for valgrind were enabled
 (despite the fact that valgrind only supports ARMv7) by building the 
 package in
 cross-compile mode and forcing the -march=armv7-a option on buildds that 
 didn't
 support ARMv7 natively. This was done so that ARMv7 armel systems could use
 valgrind (see #592614).
 
 This has sort of worked for a while, until a couple months ago when valgrind
 started FTBFS on armel (#720409). This was a simple routine rebuild for the
 openmpi transition, so I'm inclined to think that I did not broke anything
 myself. My next upload 1:3.8.1-5 (a month later) still failed to build, 
 making
 me think that this is not a transient failure.
 
 Hence the idea: what about dropping valgrind from armel? Or alternatively, 
 is
 there anyone who cares about valgrind on armel and wants to debug and try to
 fix this (possibly without making the original kinda ugly hack any worse)?
 
 So, no one? In the next few days I'm going to upload a new version disabling
 armel builds and ask the release team to drop it as well. If it turns out 
 that
 many people actually used valgrind on armel, I guess I can re-enable it later
 (once it works again).
 
 Cheers
 
 
 Are you disabling all armel builds?  Or just valgrind on armel?

Not sure if I understood the question correctly, but I was referring only to
valgrind's armel build (I don't quite have the power to eliminate a whole
Debian port I'm afraid ;)

Also, please CC me since I'm not subscibed to the list (I forgot to mention
that before).

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature


AW: New Arndale board announced

2013-10-29 Thread Bortis Kevin
Nice board. It seems that they have learned from some design flaws of their 
original arndale board design. Three things that I think are still criticall: 
1. They still have no reasonable cooling solution and no mounting holes for a 
standard cooler/fan. The orginal arndale board got overheated really fast with 
a working clock of over 1GHz and was therefor very unstable. 
2. The board is missing a SATA connector. The internal eMMC is far to slow for 
speedy sw development. 
3. There is still no working graphic driver with 3D/video acceleration that 
would work with vanilla debian. There is only an android blob available. 
Perhaps someone could try to get it running with libhybris/wayland, but this 
would be nothing more than a hack.

Regards
Kevin

 -Ursprüngliche Nachricht-
 Von: Steve McIntyre [mailto:st...@einval.com]
 Gesendet: Dienstag, 29. Oktober 2013 17:34
 An: debian-arm@lists.debian.org
 Betreff: New Arndale board announced
 
 using the new octa-core Exynos 5420:
 
 http://www.pyrustek.com/us/?menuType=productmode=viewprodCod
 e=201310213
 
 Might be interesting...
 
 --
 Steve McIntyre, Cambridge, UK.st...@einval.com
 This dress doesn't reverse. -- Alden Spiess
 
 
 --
 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/20131029163352.gj6...@einval.com


--
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/a03aec930cbb4d46b9e527d599cff4d304eb5...@srvm-mail01-shl.ruf.group



Re: AW: New Arndale board announced

2013-10-29 Thread peter green

Bortis Kevin wrote:
Nice board. It seems that they have learned from some design flaws of their original arndale board design. Three things that I think are still criticall: 
1. They still have no reasonable cooling solution and no mounting holes for a standard cooler/fan. The orginal arndale board got overheated really fast with a working clock of over 1GHz and was therefor very unstable. 
  

Indeed, the odroid XU seems better in that regard.
2. The board is missing a SATA connector. The internal eMMC is far to slow for speedy sw development. 
  
There is USB3 which should in theory give you fast storage, the question 
is will it be fast and stable in practice.


Does anyone know if the reason for the lack of SATA is because the SoC 
doesn't have it, because the vendors can't be bothered including it or 
some other reason?



--
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/526ffbbe.3090...@p10link.net



Re: AW: New Arndale board announced

2013-10-29 Thread Nigel Sollars
Hi all,

You might be on the money with the SoC not having it,  if you see the Omap5
A15 SoC it would suggest that Sata is an option.  There is a board here:
http://www.embedded.rs/

That sports a Sata2 pdf spec here:
http://www.embedded.rs/sites/default/files/EPP-Pico-OMAP5430_Datasheet.pdf

That being said, this Samsung soc is more leaning towards phone / tablet so
it might not be there.

Nige


On Tue, Oct 29, 2013 at 2:17 PM, peter green plugw...@p10link.net wrote:

 Bortis Kevin wrote:

 Nice board. It seems that they have learned from some design flaws of
 their original arndale board design. Three things that I think are still
 criticall: 1. They still have no reasonable cooling solution and no
 mounting holes for a standard cooler/fan. The orginal arndale board got
 overheated really fast with a working clock of over 1GHz and was therefor
 very unstable.

 Indeed, the odroid XU seems better in that regard.

  2. The board is missing a SATA connector. The internal eMMC is far to
 slow for speedy sw development.

 There is USB3 which should in theory give you fast storage, the question
 is will it be fast and stable in practice.

 Does anyone know if the reason for the lack of SATA is because the SoC
 doesn't have it, because the vendors can't be bothered including it or some
 other reason?



 --
 To UNSUBSCRIBE, email to 
 debian-arm-REQUEST@lists.**debian.orgdebian-arm-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive: 
 http://lists.debian.org/**526ffbbe.3090...@p10link.nethttp://lists.debian.org/526ffbbe.3090...@p10link.net




-- 
“Science is a differential equation. Religion is a boundary condition.”

  Alan Turing


Re: AW: New Arndale board announced

2013-10-29 Thread Steve McIntyre
On Tue, Oct 29, 2013 at 06:17:34PM +, peter green wrote:
Bortis Kevin wrote:
Nice board. It seems that they have learned from some design flaws
of their original arndale board design. Three things that I think
are still criticall: 1. They still have no reasonable cooling
solution and no mounting holes for a standard cooler/fan. The
orginal arndale board got overheated really fast with a working
clock of over 1GHz and was therefor very unstable.
Indeed, the odroid XU seems better in that regard.
2. The board is missing a SATA connector. The internal eMMC is far
to slow for speedy sw development.
There is USB3 which should in theory give you fast storage, the
question is will it be fast and stable in practice.

Does anyone know if the reason for the lack of SATA is because the
SoC doesn't have it, because the vendors can't be bothered including
it or some other reason?

I'm going to ask these guys today. :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You can't barbecue lettuce! -- Ellie Crane


-- 
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/20131029184645.gl6...@einval.com



Re: New Arndale board announced

2013-10-29 Thread Lennart Sorensen
On Tue, Oct 29, 2013 at 06:47:39PM +0100, Bortis Kevin wrote:
 Nice board. It seems that they have learned from some design flaws of their 
 original arndale board design. Three things that I think are still criticall: 
 1. They still have no reasonable cooling solution and no mounting holes for a 
 standard cooler/fan. The orginal arndale board got overheated really fast 
 with a working clock of over 1GHz and was therefor very unstable. 

Not sure if it would be a problem.  I am currently playing with an
early eval board with a dual Cortex-A15 at 1.5GHz without a heatsink,
and running one full out as a buildd to experiment with.  The other 10
miscelanious cores are idle at the moment, but over all I think it is
supposed to run at 2 or 3W, so that CPU there might only use 5 or 6W
running full out unless you actually decide you want to use the graphics,
which might take a bit more.

Of course the board I am playing with does have SATA and 1.5GB ram,
which I am very pleased with.

 2. The board is missing a SATA connector. The internal eMMC is far to slow 
 for speedy sw development. 

Yeah, best I have seen from eMMC so far was 28MB/s.  Better than microSD
at 20MB/s, but not SATA.

 3. There is still no working graphic driver with 3D/video acceleration that 
 would work with vanilla debian. There is only an android blob available. 
 Perhaps someone could try to get it running with libhybris/wayland, but this 
 would be nothing more than a hack.

It also looks like ethernet is connected via USB.

That and the lack of sata is just a typical problem with the CPUs designed
for use in a smartphone.

-- 
Len Sorensen


-- 
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/20131029190449.gv13...@csclub.uwaterloo.ca



Re: New Arndale board announced

2013-10-29 Thread Paul Wise
On Wed, Oct 30, 2013 at 1:47 AM, Bortis Kevin wrote:

 3. There is still no working graphic driver with 3D/video acceleration that 
 would work with vanilla debian. There is only an android blob available. 
 Perhaps someone could try to get it running with libhybris/wayland, but this 
 would be nothing more than a hack.

Which GPU does it contain? I haven't been able to find a spec sheet
that lists that.

-- 
bye,
pabs

http://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: 
http://lists.debian.org/CAKTje6E0dVUPNDzVORCQ-d=lehb9jfz1mj5jdztdghsrs6h...@mail.gmail.com