<Wizzup>
I am doing the sgx ddk stuff and headers from xf86-video-omap
<Wizzup>
and it should all go into -experimental
<Wizzup>
there's also a 5.15 kernel build for -experimental based on latest droid4 pending + maybe the patches fmg mentioned
<Wizzup>
maybe the least painful thing to do is to try with latest mesa release without pvr for -devel, and then we can try to add the pvr stuff on top of that
<Wizzup>
I'm setting up a cross container with mostly native performance using bencoh's method for stuff as well
<parazyd>
Alright, will check after lunch today
<Wizzup>
just poke me then, I might have been looking at mesa already
<Wizzup>
bencoh: fakeroot-sysv is not installed after the debootstrap for amd64 it seems
<Wizzup>
chrooting to the amd64 one and installing it
<Wizzup>
bencoh: iirc I also had to install devuan-keyring on the armhf container
pere has joined #maemo-leste
<uvos>
is HildonTextView thumb scrollable?
<bencoh>
Wizzup: if you followed the steps it should be
<bencoh>
Wizzup: I tried yesterday
<Wizzup>
it wasn't installed, but I installed it manually
<Wizzup>
pretty sure I followed all the steps this time
<Wizzup>
assuming you're taking fakeroot-sysv
<bencoh>
but I updated it with a patched fakeroot-sysv script to allow working with both armhf and amd64; I dunno if the version you have is patched
<Wizzup>
talking*
<bencoh>
Wizzup: including the xorg build-dep?
<Wizzup>
bencoh: you're right, that's the one I skipped... :)
<bencoh>
:)
<Wizzup>
in any case it works now
<bencoh>
yay
<Wizzup>
I haven't tried to build anything yet, but everything else seems ok
<Wizzup>
(I need to add leste sources and such)
<Wizzup>
btw the xorg dep is after the fakeroot-sysv so I can't matter for that
<Wizzup>
maybe it's a debootstrap on gentoo vs debian thing
<bencoh>
?
<bencoh>
ah
<Wizzup>
right, with regards to fakeroot not being installed
<bencoh>
I just realized the build-deb thing is in the armhf container, not in the chroot
<Wizzup>
yeah, but the sed on the fakeroot binary is also before that step
<Wizzup>
the only things I had to change wrt the notes was (1) suspend lxc create and install qemu before it needs it (2) install fakeroot in amd64 container/chroot (3) install fakeroot in armhf
inky has quit [Read error: Connection reset by peer]
<bencoh>
Wizzup: the build-dep happens in armhf, so basically it isn't related in any way, I was mistaken :)
<bencoh>
so we should probably add it to the list of stuff to install
<bencoh>
(for the amd64 chroot)
inky has joined #maemo-leste
<Wizzup>
probably yeah
<Wizzup>
but then the order needs to change still
<Wizzup>
as in the sed needs to then happen after the install
<bencoh>
Wizzup: the sed is amd64-related, the build-dep is armhf-related
<Wizzup>
yes
<Wizzup>
but if you meant to add fakeroot to this:
<Wizzup>
I think bencoh's container thing should make this much more painless to test btw
<Wizzup>
much less painful*
ruleh has quit [Quit: Client closed]
<Wizzup>
I volunteer to test a build later today if you want
<parazyd>
Started working on it now
<Wizzup>
*nod*
<Wizzup>
cool :)
<Wizzup>
ideally we could build 21.2.5
<Wizzup>
and add the pvr patches on top of that
<parazyd>
Yep
<Wizzup>
since that would help lima devices (presumably)
<parazyd>
That's my plan
<Wizzup>
cool
<parazyd>
Need to see if I have to update glvnd and libdrm first
<Wizzup>
right
xmn has joined #maemo-leste
ruleh has joined #maemo-leste
<uvos>
heh so i made a thread view for sphone
<uvos>
and it crashes xorg with 100% precision when rotated with it shown
<uvos>
on d4
<uvos>
like him dose soemtimes
<Wizzup>
well that's good news in the sense that we have a reproducible bug
<uvos>
i was looking for a repoducable case for this
<uvos>
yeah
<uvos>
but i think fmg is just gona save me at this point
<Wizzup>
btw, parazyd just got the reboot on upgrade again and it looks like mce cannot get dbus when it restarts and then the device reboots after 10 tries
<uvos>
with ddk1.17/new -video-omap
<Wizzup>
we're trying to see if the dbus addrs in /tmp/ get clobbered somehow
<Wizzup>
what is threaded view for sms even though?
<Wizzup>
afaik there is no way to 'respond to a thread' ?
<uvos>
sure there is
<uvos>
Wizzup: like android
<Wizzup>
I don't understand
<uvos>
well every contact has one thread, you can have multiple threads like email foc
<uvos>
*ofc
<Wizzup>
so what's a thread about it?
<Wizzup>
or do you mean what maemo does as well
<uvos>
im not describing it correctly
<uvos>
its like android or telegram or irc or whatever works
<uvos>
there are rooms
<uvos>
with recipiants
<parazyd>
You mean "groups" ?
<uvos>
yeah execpt a group is just one perso
<uvos>
since its sms
<parazyd>
Right
<uvos>
(only available backend atm anyways - its backend selectable)
<bencoh>
maemo has no real "thread" support (at least in Conversation), but it has "conversations"
<uvos>
overide it with something that links to dri/by-path/$(whateveromapdrm ist)
<freemangordon>
uvos: please, could you do that
<uvos>
sure
<freemangordon>
we need that for d4 and Nokia devices only
<freemangordon>
well, not really
<uvos>
do we want the sgx node at all?
<freemangordon>
we need it for devices with SGX GPU :)
<uvos>
or is it non operatable
<freemangordon>
uvos: no idea
<uvos>
ok
<freemangordon>
I can try without it later on
<uvos>
we need the sgx node for kmscube/plain kms/drm applicaitons or?
<freemangordon>
and, it seems we'll have to rename pvr_dri to omapdrm_dri
<freemangordon>
don;t know
<freemangordon>
and cannot test ATM
<uvos>
ok
<uvos>
ill do it later
<freemangordon>
thanks!
<dsc_>
Re: my droid4, I'm now on an USB wall charger, when I connect the d4 it turns on, into kexecboot, but quickly turns off again
<dsc_>
I am getting the feeling it is not actually charging
<dsc_>
*or* kexecboot automatically picks an item from the list (maemo) and turns black because my OS is broken (?)
<Wizzup>
I'd just leave it on the wall for ~30 mins
<dsc_>
yeah, it wont boot into stock android too
<uvos>
dsc_: pick stock android
<uvos>
ok
<uvos>
its to empty
<dsc_>
ok
<parazyd>
Can we somehow protect against this happening?
<uvos>
no
<uvos>
well we do
<uvos>
with mce
<parazyd>
How does Android do it?
<uvos>
but if it happes becasue the device is off for a long time and self0discarges we cant protect
<uvos>
so the probem is:
<uvos>
cpcap charges by itself untill some voltage is accived (unless the voltage is below 2.5 or so volts then it wont charge beause its unsafe)
<uvos>
then cpcap boots the device
<uvos>
android immidatly enters its charge mode
<uvos>
but with kexecboot, kexecboot loads first
<uvos>
the battery is then below androids emergency threshold by the time it starts
<parazyd>
aha
<uvos>
so its too late and it powers off again
<dsc_>
some sort of visual indicator it is charging at least would be nice somehow
<parazyd>
The green LED should be on
<uvos>
the green led is cpcap's hw signaling charge
<dsc_>
it is not
<parazyd>
fwiw I sometimes charge it with a DC-only USB cable (no data pins) and it helps
<parazyd>
Not sure why
<parazyd>
I think it works for buZz too
<uvos>
if the id pin is not pulled low
<uvos>
cpcap dosent boot ever
<uvos>
so it just charges while off
<dsc_>
I might have an USB cable that is not capable of delivering power (?)
<dsc_>
:D
<uvos>
no
<uvos>
you might have an usb calble thats capapble of delivering data
<dsc_>
right
<uvos>
anyhow if this happens i just remove the battery and give it a bit of juice
<uvos>
i gues you dont have anything to do that
<dsc_>
correct
<uvos>
dsc_: ok try what Wizzup said, maybe the charge led is just off because the android kernel wrote the reg to turn this feature off before it powered down
<ruleh>
try plugging it into a pc usb port, seems to work for me
<uvos>
otherwise your out of luck i think
<tmlind>
ruleh: hi again!
<dsc_>
kk
<ruleh>
HI :)
<tmlind>
the cpcap charger stuff should sort of behave nowadays
<uvos>
tmlind: this is about cpcaps trickel charge behavior before boot
<ruleh>
the low battery charging seems to be highly charger dependent for some reason
<tmlind>
uvos: right, sorry that was for ruleh to summarize the status since few years ago..
<uvos>
oh ok :)
<ruleh>
there is also this situation where the device gets power over usb to run things like fastboot but doesn't actually charge the battery.
<uvos>
ruleh: sure yeah for a855 there was the "factory" cable that powerd the device over usb and booted fastboot only
<uvos>
not sure if its implemented on xt894
<uvos>
looks like this was with pullup on the id pin
<tmlind>
hmm yeah fastboot cable with id pin pulled up will always power up the device using usb bus, even if no battery. not sure booted stock os charges battery though
<uvos>
ok on a855 this forces fastboot mode, no way to boot stock os. so thats not how xt894 works, interesting
<ruleh>
would an usb otg cable do the same?
<uvos>
no
<uvos>
otg pulls the pin down
<parazyd>
uvos, Wizzup: btw I just got 7.5G of Nov 15 12:53:53 localhost maemo-launcher[5733]: error accepting connections (Operation not supported)
<parazyd>
In /var/log/syslog
<parazyd>
It keeps filling up
<uvos>
neat
<parazyd>
lol
* parazyd
reboots
<bencoh>
best way to test the sdcard ever
<parazyd>
It was in the VM, but regardless
<Wizzup>
parazyd: maybe restarting maemo-launcher is problematic?
<uvos>
my /var/log/syslog looks fine
<uvos>
(on d4)
<parazyd>
Perhaps
<parazyd>
I'm trying to build mesa so I don't want to restart services atm
ruleh has quit [Quit: Client closed]
<uvos>
parazyd: this isent wasent on the same boot as where you upraged maemo-launcher?
<parazyd>
No, I already got ke-recv or something reboot my VM when I did a dist-upgrade
ruleh has joined #maemo-leste
<bencoh>
is dist-upgrade supposed to work nowadays?
<uvos>
yes but dsme/ke-recv broke it some time ago
xmn has quit [Ping timeout: 264 seconds]
<Wizzup>
bencoh: upgrade is mostly dist-upgrade for our purposes, unless you meant actually moving from one release to another
elastic_dog has joined #maemo-leste
<buZz>
parazyd: yep, blocking data pins on a USB cable makes charging (from zero) a -lot- easier
_inky has quit [Ping timeout: 265 seconds]
inky has joined #maemo-leste
<dreamer>
blocking?
<bencoh>
shorting to ground iirc
<bencoh>
(that's what chargers should do)
<bencoh>
(not sure if it's really shorting it to ground or having a pull-down resistor though)
ruleh has quit [Quit: Client closed]
_inky has joined #maemo-leste
elastic_dog has quit [Ping timeout: 250 seconds]
elastic_dog has joined #maemo-leste
<freemangordon>
uvos: do you want me to cc you in TILER/omapdrm mails I send to Tomi?
<freemangordon>
Wizzup: same question to you
<freemangordon>
though, linux-omap is in CC so you should already have them
pere has quit [Ping timeout: 260 seconds]
<uvos>
freemangordon: its unlikely that i can add anything, but i am happy to follow along.
<freemangordon>
yeah, it is not about helping, just FYI
<uvos>
and im on linux-omap only in with the spamy email
<uvos>
so yes
<freemangordon>
ok, will cc
<Wizzup>
freemangordon: yes please
<freemangordon>
ok
<freemangordon>
sicelo: hmm, who is that guy? should I know him?
<freemangordon>
I mean - I follow the discussion on the ML, but not sure shall I do anything about
<buZz>
you mean pavel?
<buZz>
oh different ML i guess
<buZz>
bencoh: no, just not connecting the datapins
<buZz>
so, left floating
<bencoh>
shorting D+/D- together?
<freemangordon>
buZz: I mean Lucas Fryzek
<buZz>
i dont know this person :)
<buZz>
bencoh: i have a 'usb condom' that only allows GND and +5V to connect through
<buZz>
the datapins are unconnected
<bencoh>
ah, that
<buZz>
i think i even pulled em out of the usb plugs?
<Wizzup>
freemangordon:
<Wizzup>
glmark2 Score: 92
<Wizzup>
neat
<freemangordon>
yeah :)
<freemangordon>
Xorg segfaults from time to time though, but I'll investigate
<Wizzup>
*nod*
<freemangordon>
this is with PVR EXA
<freemangordon>
without it it is stable
<Wizzup>
check
<freemangordon>
so, we have usable 5.15/1.17 :)
<freemangordon>
I'll have to resend some patches though
<parazyd>
Wizzup: Can you try building it for arm?
<parazyd>
(I don't have a proper lxc setup right now)
<Wizzup>
ok
<Wizzup>
parazyd: going to verbose about this
<Wizzup>
I run apt-get build-dep .
<Wizzup>
and get:
<Wizzup>
The following packages have unmet dependencies: builddeps:. : Depends: meson (>= 0.52) but 0.49.2-1 is to be installed
<Wizzup>
E: Unable to correct problems, you have held broken packages.
<Wizzup>
so first thing to do is install it from backports?
<Wizzup>
doing so now
<parazyd>
Yep
<parazyd>
Wizzup: oh and you have the rest of the deps in beowulf-experimental, so enable it
<parazyd>
Latest libdrm and libglvnd
<Wizzup>
yeah I did enable it
<Wizzup>
I get this:
<Wizzup>
../meson.build:305:2: ERROR: Problem encountered: tegra driver requires nouveau driver
<freemangordon>
tmlind: is there any change to have my patches *after* 5.15.2 merge
<freemangordon>
*chance
<freemangordon>
I have to send new versions, but I am not sure how to do that
<freemangordon>
I tried to git rebase -i, but it fails
<Wizzup>
what fails exactly?
System_Error has quit [Remote host closed the connection]
<Wizzup>
parazyd: any idea what to do next?
System_Error has joined #maemo-leste
<Wizzup>
trying something
<freemangordon>
the rebase itself
<freemangordon>
CONFLICT (content): Merge conflict in drivers/spi/spi-tegra20-slink.c
<Wizzup>
well, what's the conflict?
<freemangordon>
ok, I guess I can revert aand apply on top
<Wizzup>
right
<Wizzup>
parazyd: I added nouveau next to the pvr section in meson.build and it's going now, let's see
<Wizzup>
ah, nope, didn't help
<Wizzup>
meson /o\
<tmlind>
freemangordon: hmm well your patches appear after 5.12.2 if you do git log 5.12.2.. but not sure what you're trying to do
<tmlind>
i thought you wanted the stable 5.12 merged in?
<tmlind>
next week it's 5.12.3 and again they patches get buried :)
<freemangordon>
tmlind: yes, they appear after, but are actually before it seems
<freemangordon>
I want to squash a change I made into one of those patches
<freemangordon>
by using git rebase -i, but it wants to everything between 5.15-rc and 5.15.2
<freemangordon>
and fails
<parazyd>
Wizzup: Hold on, something came up here, sorry
<Wizzup>
k, np, I'll do some other stuff meanwhile
<freemangordon>
tmlind: top commit is (HEAD -> droid4-pending-pvr-omapdrm-v5.15, tmlind/droid4-pending-pvr-omapdrm-v5.15) Merge tag 'v5.15.2' into droid4-pending-pvr-omapdrm-v5.15
<freemangordon>
so it seems you have applied my patches and then merged 5.15.2 on top
<freemangordon>
not really an issue, I'll just revert and reapply
<dsc_>
Wizzup: contrary to popular belief I was not born yesterday, as such I give all my Text{} qml components the "textFormat: Text.PlainText" property :P
<uvos>
Wizzup: no i applied the chromeos patches directly and those simply applied fine.
<uvos>
Wizzup: i gues this is a difference in fmgs re pvr
<Wizzup>
those values don't exist in the gl_config struct
<Wizzup>
so maybe they applied fine but it does not build
<uvos>
well im using it
<uvos>
so it must have build :P
<uvos>
or rather i used to use it
<Wizzup>
what version?
<Wizzup>
21.2.5?
<uvos>
uh
<Wizzup>
seems quite unlikely since it doesn't even build freedreno without patches
<uvos>
idk really i just cloned mesa-git some time ago (2-3 months maybe
<uvos>
)
<uvos>
ill check in a sec
<Wizzup>
in any case I can't continue as this requires in-depth mesa knowledge, but we're getting there I guess
<Wizzup>
well I could maybe comment them if this is not used elsewhere
<Wizzup>
I'll try again later, maybe the patches were not applied well
<freemangordon>
hildon-connectivity-wlan : Depends: libicd-network-wpasupplicant-dbus-n900 but it is not installable or
<freemangordon>
libicd-network-wpasupplicant-dbus-common but it is not installable
<freemangordon>
weird
<Wizzup>
I think others remarked on this too, I haven't hit it yet
<Wizzup>
brb 10-15 mins
<freemangordon>
hmm, I upgraded and now TS does not work :(
devrtz[m] has joined #maemo-leste
<freemangordon>
uvos: xinput does not list TS, any idea?
<Wizzup>
could it be the udev rule for ts buttons?
<freemangordon>
yes, but I can;t remember what was that
<freemangordon>
ah, found it
<freemangordon>
85-input-devices.rules.leste?
<freemangordon>
I shall remove that,right?
<freemangordon>
yeah, that was it
<Wizzup>
z/win 28
<Wizzup>
oops
<devrtz[m]>
Hey there, I'm trying to organize a devroom for mobile linux related topics at fosdem and just wanted to ask if there would be some interest here in helping out or even giving a talk should my submission be accepted
<Wizzup>
fosdem is remote this year, right?
<devrtz[m]>
yup
<Wizzup>
what kind of help do you need?
<devrtz[m]>
Should it be accepted sorting through submitted talks. During the event: Coordinating with speakers, making sure everything goes smooth, that sort of thing. I'm actually not a 100% sure of all the things that need doing as I've never organized a devroom before.
<devrtz[m]>
I do have some help of people who did though :)
<freemangordon>
Wizzup: libgl1-mesa-dri:armhf depends on libllvm8 (>= 1:8~svn298832-1~); however:
<freemangordon>
mesa-vdpau-drivers:armhf depends on libllvm8 (>= 1:8~svn298832-1~);
<freemangordon>
ah, buster-backports
<Wizzup>
right
<Wizzup>
devrtz[m]: hm... I'd probably be more likely to talk about something than do a lot of emails since I already feel a bit overworked as-is, but perhaps others would like to do that?
<Wizzup>
I know some folks here were also in-person fosdem volunteers in the past
<devrtz[m]>
Yeah I actually saw the talk at the main track in '20 :)
<Wizzup>
I'm sure it'll get accepted, mobile linux is bigger than ever I think
<devrtz[m]>
Ok, cool, should the devroom get accepted I will post the CfP here!
<uvos>
wait is our 5.15 leste kernel for expiramental w/o ts-buttons now?
<Wizzup>
that probably depends entirely on fmg's config and what he used exactly, we don't have a -experimental kernel yet afaik
<uvos>
oh ok
<freemangordon>
Wizzup: mesa seems to be fine
<uvos>
freemangordon: did you see this "[17:56] <uvos> freemangordon: btw swaping card0/1 is not as trivial as i thought" and the msgs below it?
<uvos>
how bad do we need this? what i would have to do with udev is a bit of a hack
<freemangordon>
yes, but don;t know how to comment on that :)
<uvos>
ok
<freemangordon>
don;t know
<Wizzup>
freemangordon: that's great
<freemangordon>
uvos: I am not sure how to fix that
<freemangordon>
lemme try something
<ruleh>
loading omapdrm before pvr should make sure that the numbering is "correct", no?
<uvos>
so whats using card0?
<freemangordon>
I guess, but we can;t guarantee that afaik
<uvos>
video-omap?
<uvos>
mesa?
<freemangordon>
mesa
<ruleh>
modprobe.d can enforce some sort of ordering I think
<uvos>
yeah that would work too but i dont think its so great.
<freemangordon>
lemme see if symlinking pvr_dri to omapdrm_dri will help
<uvos>
might be better to ajust whatever uses the device to check what its binding to
<Wizzup>
freemangordon: so as far as you are concerned we can build this mesa in -experimental ?
<freemangordon>
yes
<Wizzup>
ok
<freemangordon>
well, I think "export MESA_LOADER_DRIVER_OVERRIDE=pvr" in /etc/profile/d is the least hacky solution
<uvos>
freemangordon: do you know where the logic is in mesa what plugin+rener node to use
<freemangordon>
no
<uvos>
ok
<Wizzup>
it's should be a decent solution for now yeah
<freemangordon>
so please, whoever maintains those, add it for d4 and n900
<uvos>
parazyd: ^^^
<Wizzup>
leste-config yeah?
<Wizzup>
for experimental?
<freemangordon>
dunno
<freemangordon>
but yeah, for experimental
<uvos>
yeah leste config
<uvos>
export MESA_LOADER_DRIVER_OVERRIDE=pvr should not do anything bad on current devel i think
<uvos>
but yeah experimaental is more safe
<freemangordon>
this mesa gives glmark 85 in portrait and 96 in landscape
<freemangordon>
that's good I guess
<freemangordon>
hildon scrolling: *** FPS: 83 ***
<uvos>
might want to cap hildon at 60
<uvos>
even in the absence of vsync
<uvos>
no need to torture the battery
<freemangordon>
yeah
sunshavi has quit [Remote host closed the connection]
ruleh has quit [Quit: Client closed]
ruleh has joined #maemo-leste
mardy has quit [Quit: WeeChat 2.8]
sunshavi has joined #maemo-leste
ruleh has quit [Quit: Client closed]
ruleh has joined #maemo-leste
uvos has quit [Ping timeout: 256 seconds]
sunshavi has quit [Remote host closed the connection]
<Wizzup>
freemangordon: was there anything you wanted the sgx-ddk-um to depend on?
<freemangordon>
I don;t think so
<Wizzup>
ok
sunshavi has joined #maemo-leste
ruleh has quit [Quit: Client closed]
<Wizzup>
freemangordon: what about /usr/include/sgx/{hwdefs,include4} ?
<Wizzup>
unless you really want to use the full kernel path?
uvos has joined #maemo-leste
<Wizzup>
freemangordon: and for the .pc file, you want the -I CFLAGS, and what libs do you want to link against?
ruleh has joined #maemo-leste
xmn has joined #maemo-leste
<freemangordon>
Wizzup: -lsrv_um -lpvr2d
<Wizzup>
ok
<Wizzup>
freemangordon: I guess we want the ti443x and ti343x to conflict
sunshavi has quit [Remote host closed the connection]
<Wizzup>
freemangordon: can I push to xf86-video-omap for the new -dev pkg and pkgconfig stuff?
<Wizzup>
I guess we also need some meta pkg for the sgx-ddk-um libs that pulls in the device libs
<Wizzup>
we could also make them go in separate components I guess
<Wizzup>
maybe 'Provides: sgx-ddk-um-libs' ?
<Wizzup>
freemangordon: what about these: -DLINUX -DSGX540 -DSUPPORT_DMABUF
inky has quit [Ping timeout: 265 seconds]
<Wizzup>
bencoh: getting this btw: man: error while loading shared libraries: libmandb-2.8.5.so: cannot open shared object file: No such file or directory
<Wizzup>
maybe some divert or lib missing
_inky has quit [Ping timeout: 256 seconds]
<Wizzup>
LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/amd64/usr/lib/man-db" man
<Wizzup>
this works
<Wizzup>
(this is a problem because dh_installman errors)
<bencoh>
I don't think you should need to do that, but I remember having some issue with mandb
<bencoh>
dh_installman doesn't seem to fail here though
<bencoh>
which package did you fail to build?
<Wizzup>
xf86-video-omap
<bencoh>
from git?
<Wizzup>
from our git yeah
<Wizzup>
bencoh: does 'man' work from the shell?
<Wizzup>
freemangordon: pushed to pvr-exa-pkg
<Wizzup>
(on xf86-video-omap)
<bencoh>
Wizzup: looks like it does
<Wizzup>
weird
<bencoh>
I think it didn't work at some point, but it does now, even in the container I created yesterday
<bencoh>
so I guess I fixed that somehow (?)
<Wizzup>
freemangordon: so what needs fixing still is that the build needs pvr2d.so and libsrv_um.so, which are part of device-specific packages, so I don't know what to ship in -dev
<bencoh>
dpkg-buildpackage: info: binary-only upload (no source included)
<bencoh>
real 1m26.293s
<Wizzup>
weird
<bencoh>
using the source from apt-get source
<Wizzup>
I mean yeah it should work if man works :)
<Wizzup>
but my 'man' command errors out
<Wizzup>
which debian also invokes
<Wizzup>
with the LD_LIBRARY_PATH change it also builds for me
<bencoh>
I think you're missing a divert because of some package that wasn't installed at the time you ran the divert lines
<Wizzup>
hm
<bencoh>
(back to the xorg build-dep thing)
<Wizzup>
hehe
<Wizzup>
can I just re-run the divert lines or will that not work?
<bencoh>
I wonder what would happen if you re-run it for stuff that was already diverted
<Wizzup>
right, that's what I mean
<bencoh>
you could try running the ones related to man/man-db
<uvos>
Wizzup: a955, same as a855 except with 2x the ram. Also sim locked unless its the global variant (hard to tell) then its unlocked outside the us like xt894.
<uvos>
25euros is also about the going rate in germany of a953/2/0 that are not simlocked
<uvos>
so not usefull no
<uvos>
also locked bootloader btw unlike a855 but like a85x