<freemangordon>
hmm, we have a nasty issue with tinymail - it has the so-called camel-lite library, which seems to be copy-pasted code from some unknown eds version
<freemangordon>
it would all be fine if both libcamel-lite-1.2.so.0.0.0 and libcamel-1.2.so.62.0.0 were not exporting the same symbols :(
<freemangordon>
hmm, maybe I shall symply fix the soname
<freemangordon>
if that even matters
<freemangordon>
sonames are fine
<freemangordon>
I wonder if it makes sense
<freemangordon>
to port to libcamel
<freemangordon>
I don't understand what is so 'lite' in libcamel-lite
<freemangordon>
anyway we pull eds
mardy has quit [Ping timeout: 256 seconds]
xmn has quit [Ping timeout: 240 seconds]
mepy_ has quit [Quit: Leaving]
<Wizzup>
freemangordon: heh
<freemangordon>
yeah
<freemangordon>
the issue is that osso-abook pulls eds libs and they try to init their own camel implementation, but camel-lite get called instead :)
<freemangordon>
and it becomes a mess
<freemangordon>
trying to port tinymail to eds libcamel ATM
<Wizzup>
ok
<freemangordon>
seems not that hard, but wonder if we are going to lose something
<Wizzup>
it shouldn't be booted to in rescue mode I think
<humpelstilzchen[>
not really a rescue mode, but it broken X should not prevent network or getty to run
<Wizzup>
mhm
<Wizzup>
how would you connect to wifi with X not running?
<humpelstilzchen[>
On the pine I can attach an USB-Ethernet
<Wizzup>
ok
<Wizzup>
btw, usbnet should work
<Wizzup>
but how does usb-ethernet help you
<Wizzup>
I don't think it would auto connect?
<humpelstilzchen[>
it does, probably because I configured it do so. Don't think this configuration is default.
<humpelstilzchen[>
Well worst case is to login on tty and run "dhclient eth0"
<Wizzup>
ok
Oksanaa has quit [Ping timeout: 272 seconds]
<humpelstilzchen[>
tty1
<Wizzup>
on recovery mode there is also the tty keyboard
<Wizzup>
does that work on pine?
<humpelstilzchen[>
have not tested that yet
Pali has joined #maemo-leste
<freemangordon>
hmm, porting to libcamel is not that easy as I initially thought :(
<freemangordon>
maybe will do a static link
elastic_dog has quit [Quit: elastic_dog]
elastic_dog has joined #maemo-leste
xmn has joined #maemo-leste
mepy has joined #maemo-leste
macros_ has joined #maemo-leste
macros_ has quit [Ping timeout: 245 seconds]
xmn has quit [Ping timeout: 272 seconds]
<freemangordon>
Wizzup: we have a task - port tinymail-camel to upstream libcamel (for leste only that is)
<freemangordon>
it is not that hard, I would guess a week should be enough
<Wizzup>
can you make an issue for it as well?
<freemangordon>
ok
<freemangordon>
yeah, LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libcamel-lite-1.2.so.0 ./lib/test_contact_chooser makes it crash :(
<freemangordon>
Wizzup: what do you think, instead of porting, could we just rename the functions?
<freemangordon>
I know this is ugly, but at least temporarily
<freemangordon>
I was so excited that modes compiles with osso-abook enabled and now this :(
macros_ has joined #maemo-leste
macros_ has quit [Ping timeout: 256 seconds]
<Wizzup>
freemangordon: I will look in 30mins
<bencoh>
freemangordon: what about renaming the symbols? (bsed?)
uvos has joined #maemo-leste
macros_ has joined #maemo-leste
<bencoh>
ohwell, looks like you reached that conclusion as well
macros_ has quit [Ping timeout: 256 seconds]
<freemangordon>
bencoh: what is bsed?
<freemangordon>
some mass rename?
<bencoh>
bbe* (a binary sed), I thought I only had blob libs
<bencoh>
s/I only/you only/
<freemangordon>
seems objdump can do similar thing, but they say it is not a good idea to do it for .so files
<freemangordon>
but we have the source here, so we can rename
<freemangordon>
the problem is that it is about hondreds of symbols :(
<bencoh>
well, you need to be careful with string size to keep proper offsets
<freemangordon>
*hundreds
<bencoh>
so I'd only replace a few chars in the name
<bencoh>
I mean, I'd replace all the symbol names, but make sure it retains the same size
<freemangordon>
ah, I see
<bencoh>
we're talking about a C-only lib, right? no C++ involved?
<freemangordon>
c-only
<freemangordon>
oh, it is objcopy, not objdump
<bencoh>
at least you don't have to worry about c++ (de)mangling
<bencoh>
I think you should be fine
<freemangordon>
yeah
<bencoh>
I didn't know objcopy could do that, but I doubt it would allow mass-renaming anyway
<freemangordon>
could you help me with sed?
<freemangordon>
like, do you know how I shall invoke it
<bencoh>
with bbe* you mean ... here is an example: bbe -e 's/amd64/armhf/' /var/lib/lxc/maemo-leste-armhf/rootfs/amd64/usr/bin/dpkg
<freemangordon>
thanks
<bencoh>
you might need to append 'g' at the end (like sed), I'd need to check that
<bencoh>
no need for 'g'
<freemangordon>
ok
<bencoh>
slightly offtopic, but I'd love to hear your thoughts on radare2/retdec/ghidra vs IDA, assuming you ever tried either of those (I know you use IDA :) )
<freemangordon>
yep, tried it about an year ago
<freemangordon>
maybe I am used to IDA, but I think it goes circles about ghydra
<bencoh>
ah
<freemangordon>
it might have improved since then
<freemangordon>
last version I tried was ghidra 9.2.3.PUBLIC
<freemangordon>
keep in mind I fed it with complex .so (not sure which one, maybe abook)
<freemangordon>
also, the fault could be on my side by not knowing how to use it properly
<bencoh>
I've used radare2 on various occasions for analysis, and retdec/r2ghidra for decompiling, but the decompilation output really feels ... disappointing
<bencoh>
I somehow recalled IDA giving better results
<freemangordon>
yeah, I am talking about the decompiler
<bencoh>
ah :)
<freemangordon>
also, I exported a project from IDA and imported in ghidra
<bencoh>
(I'm mostly feeding it bootloaders and similar blobs here)
macros_ has joined #maemo-leste
<freemangordon>
it failed to recognize lots of types
<freemangordon>
but again, ghidra directory date is 25 may 2021 :)
<bencoh>
yeah, it might have improved since then ... although your feedback is quite similar to what I just experienced with r2ghidra
<bencoh>
(ghidra decompiler integration into radare2)
<freemangordon>
not that I know what radare2 is :)
<bencoh>
yet another SRE / binary analysis framework
<freemangordon>
anyway, lemme see if I can make modest work with abook
<bencoh>
:)
<freemangordon>
bencoh: umm, ' bbe -e 's/camel_/goose_/' /usr/lib/x86_64-linux-gnu/libcamel-lite-1.2.so.0' dumped the binary to the screen
macros_ has quit [Ping timeout: 256 seconds]
<Wizzup>
freemangordon: maybe jut rename for now I think
<freemangordon>
./lib/test_contact_chooser: symbol lookup error: /usr/lib/x86_64-linux-gnu/libcamel-lite-1.2.so.0.0.0: undefined symbol: goose_sasl_ntlm_authtype
<freemangordon>
I renamed with bbe -e 's/camel_/goose_/' /usr/lib/x86_64-linux-gnu/libcamel-lite-1.2.so.0.0.0 > libcamel-lite-1.2.so.0.0.0 and then copied the file
<freemangordon>
maybe I am missing something obvious, but still
<Wizzup>
but wait, why can't you rename the src files that have the conflicting names?
<freemangordon>
Wizzup: because we talk about hundreds of functions
<freemangordon>
it is not about renaming th efilesd
<freemangordon>
*files
<freemangordon>
we have conflicting symbols (functions)
<Wizzup>
ok
<freemangordon>
oh, bbe does not support regexes
macros_ has joined #maemo-leste
<uvos>
how is binary patching the so a sane approche here
<freemangordon>
it is not
<freemangordon>
I want it just for testing
macros_ has quit [Read error: Connection reset by peer]
<freemangordon>
uvos: if you have a better idea, please...