Bug#1025213:

[wh]

I was able to build a copy of the libgl1-mesa-dri with the Gallium i915
driver enabled, and that fixed the flickering problem on my netbook from
that era.

Here's a copy if anyone would like to try
https://github.com/wh0/debian-mesa-i915g/releases/tag/22.3.0-1-1

I saw that Fedora had enabled it too:
https://bugzilla.redhat.com/show_bug.cgi?id=2100212

Bug#832395: ddclient: Reset $ipv6 per host instead of per service

[wh]

I tried it, just modifying /usr/sbin/ddclient. It works now.

I don't have any Perl programming experience; there's got to be a more
idiomatic way than initializing it to 0 and then conditionally assigning 1.

On Thu, Jul 28, 2016, 8:41 PM Torsten Landschoff 
wrote:

> Hi,
>
> On 07/25/2016 03:16 AM, micror...@gmail.com wrote:
> > Setting 'usev6' for a host in ddclient.conf poisons subsequent hosts.
> >
> > http://sources.debian.net/src/ddclient/3.8.3-1.1/ddclient/#L867
>
> good catch!
>
> > This part of the code turns on the $ivp6 flag and leaves it on for the
> > rest of the hosts associated with the same service. It's not until it
> > gets to the next service that it resets $ipv6 on line 860.
> >
> > I have an IPv4 hostname that comes alphabetically after an IPv6
> > hostname, so could you move the `my $ipv6 = 0` down to, say, line 866?
>
> that sounds like you are able to change that locally on your system. If
> you did, did that fix the problem?
> If not, I can build an experimental package for you to evaluate that
> change. Unfortunately, I don't currently have a testing system with iPv6
> connectivity...
>
> Greetings, Torsten
>
>

Bug#817929:

[wh]

(can't see my previous message. resending.)
#0  0x in ?? ()
#1  0xb7be786c in execute_helper (master_fd=master_fd@entry=5,
argv=argv@entry=0xbfffebbc) at iface.c:110
#2  0xb7be79d3 in utempter_add_record (master_fd=5, hostname=0xb28c
"mosh [3749]") at iface.c:146
#3  0x80006d59 in run_server (with_motd=, verbose=, colors=, command_argv=,
command_path="/bin/bash", desired_port=,
desired_ip=) at mosh-server.cc:498
#4  main (argc=, argv=0xb494) at mosh-server.cc:322

http://sources.debian.net/src/libutempter/1.1.6-3/iface.c/#L110
SIGSEGV for calling fork()? I can't figure this out.

Bug#817929:

[wh]

I have the same problem. I found that in dmesg, there were several lines
about mosh-server crashing by segfault, for example:

[ 2980.423340] mosh-server[7104]: segfault at 0 ip (null) sp bfd4bb6c error
14 in mosh-server[80001000+58000]

Here's some info from running mosh-server in GDB. I don't have debugging
symbols though. I'm on i386 unstable.

(gdb) c
Continuing.

mosh-server (mosh 1.2.5) [build mosh 1.2.5]
Copyright 2012 Keith Winstein 
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

[mosh-server detached, pid = 7803]
[New process 7817]
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".
Reading symbols from
/usr/lib/debug/.build-id/c6/7504492553f5afa0f618b16c92503a945af3ea.debug...done.
Reading symbols from
/usr/lib/debug/.build-id/af/a2e42e2dbf1580b3978c0810f5f4e930f3a24e.debug...done.
Reading symbols from
/usr/lib/debug/.build-id/7b/6848177dab9b5cd74f85e7dfa158bed12f5e3e.debug...done.
Reading symbols from
/usr/lib/debug/.build-id/25/b9bceb62bd6179ae5ad4bbbd9a8e612ce4189a.debug...done.

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0xb7be786c in ?? () from /usr/lib/i386-linux-gnu/libutempter.so.0
#2  0xb7be79d3 in utempter_add_record () from
/usr/lib/i386-linux-gnu/libutempter.so.0
#3  0x80006d59 in main ()
(gdb) info share
>FromTo  Syms Read   Shared Object Library
0xb7fa4240  0xb7fb03a4  Yes (*) /lib/i386-linux-gnu/libtinfo.so.5
0xb7ec1910  0xb7f60784  Yes (*) /usr/lib/i386-linux-gnu/libprotobuf.so.9
0xb7e62890  0xb7e70241  Yes
/lib/i386-linux-gnu/i686/cmov/libpthread.so.0
0xb7e04f70  0xb7e487b4  Yes (*)
/usr/lib/i386-linux-gnu/i686/cmov/libssl.so.1.0.2
0xb7c51a40  0xb7d7a6b4  Yes (*)
/usr/lib/i386-linux-gnu/i686/cmov/libcrypto.so.1.0.2
0xb7c08a30  0xb7c09326  Yes
/lib/i386-linux-gnu/i686/cmov/libutil.so.1
0xb7bec8f0  0xb7bfd122  Yes (*) /lib/i386-linux-gnu/libz.so.1
0xb7be76c0  0xb7be7b64  Yes (*) /usr/lib/i386-linux-gnu/libutempter.so.0
0xb7ae3290  0xb7b90de4  Yes (*) /usr/lib/i386-linux-gnu/libstdc++.so.6
0xb7a2d5a0  0xb7a5ec5f  Yes /lib/i386-linux-gnu/i686/cmov/libm.so.6
0xb7a0e080  0xb7a237d5  Yes (*) /lib/i386-linux-gnu/libgcc_s.so.1
0xb786b600  0xb7997fbd  Yes /lib/i386-linux-gnu/i686/cmov/libc.so.6
0xb7fdc830  0xb7ff4930  Yes /lib/ld-linux.so.2
0xb784ea30  0xb784f961  Yes /lib/i386-linux-gnu/i686/cmov/libdl.so.2
0xb7fcce00  0xb7fd1613  Yes
/lib/i386-linux-gnu/i686/cmov/libnss_compat.so.2
0xb7690110  0xb769bd11  Yes
/lib/i386-linux-gnu/i686/cmov/libnsl.so.1
0xb7681960  0xb7687c50  Yes
/lib/i386-linux-gnu/i686/cmov/libnss_nis.so.2
0xb766ea50  0xb76749c2  Yes
/lib/i386-linux-gnu/i686/cmov/libnss_files.so.2
(*): Shared library is missing debugging information.

Bug#747051: libjavascriptcoregtk-3.0-0: regular expression matching wrong on armel

[wh]

update:

turns out you actually have to turn on the fixup trap

$ echo 2 | sudo tee /proc/cpu/alignment
3
$ jsc
 '-ab'.match(/ab/)
ab

https://wiki.debian.org/ArmEabiFixes#word_accesses_must_be_aligned_to_a_multiple_of_their_size
Though this wiki page recommends, you cannot rely on this being enabled on
users' machines.

Bug#747051: libjavascriptcoregtk-3.0-0: regular expression matching wrong on armel

[wh]

This has been hard, because for some reason, in remote debugging, I can't
step or continue once I've hit a breakpoint. Anyway, I've gotten through to
the suspicious behavior by stepping through the assembly on the device. The
weird stuff happens in YARR-generated code, so there's no symbols there
anyway.

Findings:

The YARR engine attempts to use the ldrh instruction to do unaligned
halfword loads. The generated code does this to compare two characters at a
time (to match the AT part). Apparently, my device's CPU (ARM926EJ-S, I
believe) just ignores the 1's bit of the address, so that it always loads
aligned halfwords. Thus, for the test case, it gets ea at offset 0, ea
again at offset 1, and t- at offset 2. That explains why eeat- matches.
In further experiments, eeeat- doesn't match, and at- matches.

Does the Linux debian-armel 2.6.32-5-versatile #1 Wed Jan 12 23:05:11 UTC
2011 armv5tejl GNU/Linux allow unaligned ldrh or something?

Bug#747051: libjavascriptcoregtk-3.0-0: regular expression matching wrong on armel

[wh]

Here's a disassembly of the pattern /AT\W/i.

http://paste.debian.net/98876/

High level overview: a loop starts at 0xb390a038. r0 is a pointer to the
string, and r1 is the current search index plus 3.
- it does a halfword load, converts it to lowercase, and checks it against
at
- if it's not equal, it jumps to 0xb390a08c to increment r1 and repeats

The code that matches at comes from here:

http://sources.debian.net/src/webkitgtk/2.4.1-2/Source/JavaScriptCore/yarr/YarrJIT.cpp#L841

which either comes from

http://sources.debian.net/src/webkitgtk/2.4.1-2/Source/JavaScriptCore/assembler/MacroAssemblerARM.h#L412

or

http://sources.debian.net/src/webkitgtk/2.4.1-2/Source/JavaScriptCore/assembler/MacroAssemblerARMv7.h#L616

It's just a plain old load16. Is unaligned transfer just a requirement of
the armel port? How do armv5t targets usually support it?

I learned of a kernel configuration option, CONFIG_ALIGNMENT_TRAP, which is
enabled on the kernel I'm using. The documentation suggests that it
pertains to 32-bit transfers though.

Bug#747051: libjavascriptcoregtk-3.0-0: regular expression matching wrong on armel

[wh]

I made progress on getting gdb to work. It turns out I was loading the
symbol file wrong, causing gdb to map it to the wrong address, which
explains the Cannot access memory at messages. I'll try to step through
starting at JSC::stringProtoFuncMatch to see what happens.

No real findings so far.

Bug#747051: libjavascriptcoregtk-3.0-0: regular expression matching wrong on armel

[wh]

I only have one armel device. It's one of those super-cheap netbooks. Since
the test passed for Alberto though, I have no idea what would cause it.

The test worked correctly on a amd64 virtual machine though.

I made a few attempts to run jsc in gdb. First, there's not enough RAM on
the device to load the symbols. Second, when I tried to use gdbserver and
connect to it on an Ubuntu machine (amd64, used gdb-multiarch), gdb showed
some Cannot access memory at address 0x... messages and wouldn't set a
breakpoint. Turns out that Ubuntu (trusty) distributes a different version
of gdb, so maybe that's causing a problem.

No real findings so far.


On Fri, May 9, 2014 at 3:55 AM, Alberto Garcia be...@igalia.com wrote:

 On Thu, May 08, 2014 at 12:08:40PM -0700, wh wrote:

  welp, I'd better try debugging it or something.

 We would appreciate if you can keep us up-to-date with your findings
 (did you try in more machines? does it only fail in armel? etc.)

 Thanks!

 Berto

Bug#747051: libjavascriptcoregtk-3.0-0: regular expression matching wrong on armel

[wh]

welp, I'd better try debugging it or something.

Thanks for trying it out.


On Thu, May 8, 2014 at 6:15 AM, Alberto Garcia be...@igalia.com wrote:

 On Mon, May 05, 2014 at 05:57:04AM +, microrffr+debian@gmail.comwrote:

  In jsc from libjavascriptcoregtk-3.0-bin:
 
   'eat-'.match(/AT\W/i)
  null
   'eeat-'.match(/AT\W/i)
  at-

 I cannot seem to reproduce this.

 $ jsc
  'eat-'.match(/AT\W/i)
 at-
  'eeat-'.match(/AT\W/i)
 at-
 

 $ uname -a
 Linux debian-armel 2.6.32-5-versatile #1 Wed Jan 12 23:05:11 UTC 2011
 armv5tejl GNU/Linux

 ii  libjavascriptcoregtk-3.0-02.4.1-2
 ii  libjavascriptcoregtk-3.0-bin  2.4.1-2
 ii  libc6 2.18-5
 ii  libgcc1   1:4.9.0-2
 ii  libglib2.0-0  2.40.0-3
 ii  libicu52  52.1-3
 ii  libstdc++64.9.0-2
 ii  multiarch-support 2.18-5
 ii  zlib1g1:1.2.8.dfsg-1

 Berto

Bug#736119: indentation in python-apt docs

[wh]

Package: python-apt
Version: 0.9.1

in doc/source/library/apt_pkg.rst, lines 718, 726, 736 have different
indentation from the other attributes.

rendition:
http://apt.alioth.debian.org/python-apt-doc/library/apt_pkg.html#apt_pkg.Package