Hi all,
[apologies in advance for the spam nature of this message]
I have been using a tool for remote collaboration and problem solving
that I find perfect in the context of remote collaboration. It allows
you to very easily share a terminal session even behind most firewalls
etc.
If you're interested, take a look at http://tmate.io/
It's based on tmux keymappings and configuration so if you already use
that, you will be extra happy.
-Christoffer
koen, fathi, riku,
i am having issues with auto-serial-console that was initially done by marcin.
https://git.linaro.org/gitweb?p=openembedded/meta-linaro.git;a=tree;f=meta-…
the main issue is that it conflicts with BSP layer that uses
SERIAL_CONSOLE variable. It is very much expected for a BSP layer to
set SERIAL_CONSOLE variable. In which case OE will automatically start
a serial console
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/sysvi…
So when using auto-serial-console with a 'proper' BSP layer that set
SERIAL_CONSOLE(S) we end up with starting the console twice, one added
by OE, one by auto-serial-console. So far, all our OE builds are not
using a proper BSP layer, so that's why you don't see the problem, but
for our builds we use proper BSP layer...
right now, auto-serial-console does 3 things:
1- figure out the serial console port from /proc/cmdline
2- start a console on #1
3- automatically login as root
I believe that we should 'do something' to split them into several
packages so that we get more granularity. At least #3 needs to be
separated out, as #3 is a 'policy'.
I would almost expect that 'being able to automatically login as root
on the console' is a feature that could (should?) be added to oe-core
somehow. What do you think koen? I looked into that, but there isn't
any obvious (and trivial) way to do that, but it's certainly doable
inside an IMAGE_FEATURE for example.
this email is just to start the discussion and get some advices, e.g.
i am not asking you to do it ;-) i can work on it, but want to make
sure i do it right, with an 'upstream' path if possible.
thx
nico
Hi Thorsten,
The 'lstat' issue is fixed now and with this fix, only 3 tests fail on mksh
all of which are ignored as below.
......
pass ./check.t:history-subst-4
pass ./check.t:history-subst-5
FAIL ./check.t:history-ed-1 (ignored)
Description:
Basic (ed) editing works (assumes you have generic ed editor
that prints no prompts). This is for newish ed(1) and
stderr.
unexpected exit status 32512 (exit-code 127), expected 0
unexpected stdout - got too little output
wanted:
abc def
FOOBAR def
got:
abc def
unexpected stderr - wanted pattern:
/^X*13\n16\necho FOOBAR def\nX*$/
got:
XX/home/root/anilss/pkgs/klibc/native_arm64/mksh/mksh:
/bin/ed: not found
X/home/root/anilss/pkgs/klibc/native_arm64/mksh/mksh:
<stdin>[3]: s/abc/FOOBAR/: not found
X/home/root/anilss/pkgs/klibc/native_arm64/mksh/mksh:
<stdin>[4]: w: not found
X/home/root/anilss/pkgs/klibc/native_arm64/mksh/mksh:
<stdin>[5]: q: not found
X
[incomplete last line]
FAIL ./check.t:history-ed-2 (ignored)
Description:
Correct command is edited when number given
unexpected exit status 32512 (exit-code 127), expected 0
unexpected stdout - got too little output
wanted:
line 1
line 2 is here
line 3
line 4
line 2 is changed
got:
line 1
line 2 is here
line 3
line 4
unexpected stderr - wanted pattern:
/^X*20\n23\necho line 2 is changed\nX*$/
got:
XXXXX/home/root/anilss/pkgs/klibc/native_arm64/mksh/mksh:
/bin/ed: not found
X/home/root/anilss/pkgs/klibc/native_arm64/mksh/mksh:
<stdin>[6]: s/is: not found
X/home/root/anilss/pkgs/klibc/native_arm64/mksh/mksh:
<stdin>[7]: w: not found
X/home/root/anilss/pkgs/klibc/native_arm64/mksh/mksh:
<stdin>[8]: q: not found
X
[incomplete last line]
FAIL ./check.t:history-ed-3 (ignored)
Description:
Newly created multi line commands show up as single command
in history.
unexpected stdout - first difference: line 2, char 1 (wanted 'F',
got 'a'
wanted:
abc def
FOOBAR def
a new line
1 echo abc def
2 echo FOOBAR def
3 echo a new line
got:
abc def
a new line
1 echo abc def
2 fc echo
3 s/abc/FOOBAR/
4 $a
5 echo a new line
6 .
7 w
8 q
unexpected stderr - wanted pattern:
/^X*13\n32\necho FOOBAR def\necho a new line\nX*$/
got:
XX/home/root/anilss/pkgs/klibc/native_arm64/mksh/mksh:
/bin/ed: not found
X/home/root/anilss/pkgs/klibc/native_arm64/mksh/mksh:
<stdin>[3]: s/abc/FOOBAR/: not found
XXX/home/root/anilss/pkgs/klibc/native_arm64/mksh/mksh:
<stdin>[6]: .: missing argument
X/home/root/anilss/pkgs/klibc/native_arm64/mksh/mksh:
<stdin>[7]: w: not found
X/home/root/anilss/pkgs/klibc/native_arm64/mksh/mksh:
<stdin>[8]: q: not found
XX
[incomplete last line]
pass ./check.t:IFS-space-1
. . .
pass ./check.t:debian-117-4
pass ./check.t:case-zsh
pass ./check.t:case-braces
pass ./check.t:command-shift
pass ./check.t:duffs-device
Total failed: 3 (3 ignored)
Total passed: 433
Thanks and Regards,
Anil
On 10 October 2013 01:45, Thorsten Glaser <tg(a)mirbsd.de> wrote:
> Neil Williams dixit:
>
> >The only failure which did not have an (ignored) tag was:
> >
> >FAIL ./check.t:glob-bad-2
>
> Hrm okay. This may indicate that lstat(2) is broken, or it
> may just be a problem with the test environment (this test
> is disabled on some architectures as it relies on a dangling
> symlink to be tested for being not dereferenced).
>
> What does lstat("foo") report for 'ln -s nonexistent foo'?
>
> bye,
> //mirabilos
> --
> "Using Lynx is like wearing a really good pair of shades: cuts out
> the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
> -- Henry Nelson, March 1999
>
Hi all,
As suggested in this wiki page (
http://www.omappedia.org/wiki/Power_Management_Debug_and_Profiling#Tracing_…),
I tried to use the pm_debug debugfs. However, I don't understand the bottom
half of the output. If I type "cat /sys/kernel/debug/pm_debug/count", the
bottom half of the output looks like this:
per_clkdm->per_pwrdm (11)
usbhost_clkdm->usbhost_pwrdm (0)
cam_clkdm->cam_pwrdm (0)
dss_clkdm->dss_pwrdm (0)
core_l4_clkdm->core_pwrdm (8)
core_l3_clkdm->core_pwrdm (4)
d2d_clkdm->core_pwrdm (0)
sgx_clkdm->sgx_pwrdm (0)
iva2_clkdm->iva2_pwrdm (0)
neon_clkdm->neon_pwrdm (0)
mpu_clkdm->mpu_pwrdm (0)
prm_clkdm->wkup_pwrdm (0)
cm_clkdm->core_pwrdm (0)
I tried to google what these mean, but found nothing. Please help! Thanks.
--
Regards,
Chao Xu
Hello all,
We have some scheduled downtime on snapshots.linaro.org.
This has been been planned for Friday 11th October at 3PM (UTC +1).
Downtime should be around 1 hour, hopefully shorter.
Will announce a email once maintenance is complete.
Thanks
Ben Copeland
Debconf13 (last week) considered the matter of bare-metal
cross-toolchains in Debian. Ideally we would have one toolchain source
package from which the existing linux native compilers, and
cross-compilers are built, including bare-metal cross-compilers. There
is already mechanism for adding patches for particular gcc builds, so
so long as the patch set is manageable and trackable, this would be
nice, and futureproof, as eventually the patch set should just
evaporate as it gets upstreamed.
The alternative it to simply repack the existing linaro
cross-toolchain sources, but them we get to keep doing that for new
releases, and we have gratuitous extra copies of gcc sources and
corresponding differences between A* and M* toolchains/versions.
The linaro embedded toolchains
(https://launchpad.net/gcc-arm-embedded/4.7/4.7-2013-q1-update) are
good, and work, both for M0 and M3. But building nominally the same
thing from upstream gcc gets something where M3 works but M0 doesn't.
Also they are gcc 4.7 based whilst Debian is moving to a 4.8 default.
We peered at checkouts from linaro and upstream and tried to work out
what the linaro patch-set for this toolchain is, and exactly where it
branched off upstream, but it was confusing with a lot of noise due to
version skew around some actually relevant changes.
So, in order to work out if we can in fact build our bare-metal
toolchains from the same sources as the existing toolchains we need to
know what the actual patch-set you are maitaining looks like, and what
is already upstreamed in which gcc branch/release and when the
remaining patches will go upstream. Also what the 4.7 vs 4.8 status
is. Knowing how this stuff is tracked might be even more useful over
the longer term.
Is there such info online somewhere? If not please elaborate. A
mechanism for keeping the (newly-formed) Debian cross-compiler team
sufficiently in the loop is probably what's needed in the longer term,
unless this is all just about to get upstreamed anyway and the issue
will soon become moot...?
There was also discussion around the concept of making existing
linux-arm cross-compilers, with M0 and M3 support included, and using
spec-file jiggery-pokery to get them to DTRT for M* targets. This
should be possible, but advice from anyone who's every actually tried
on the gotchas would be good.
cheers
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/