**** BEGIN LOGGING AT Tue Jun 05 03:00:15 2018
Jun 05 05:07:26 <DocScrutinizer05> moo
Jun 05 05:08:15 <DocScrutinizer05> haha yeah, perl, a nightmare
Jun 05 05:10:53 <DocScrutinizer05> don't get me wrong, perl sure is powerful an all that, but sorry it makes me puke to read do-blabla-some-bullshit-etc-pp UNLESS condition
Jun 05 05:11:48 <DocScrutinizer05> I'm used to reading stuff top-down and left-right, and evaluating conditions for doing something BEFORE I start doing it
Jun 05 05:18:45 <DocScrutinizer05> on https://de.wikipedia.org/wiki/USS_Michael_Murphy_(DDG-112) Captain: "FIRE... unless this is a drill"
Jun 05 05:24:19 <jonwil> I think I finally got this working
Jun 05 05:49:05 <ceene> jonwil: great!
Jun 05 05:49:15 <ceene> are you uploading your progress somewhere?
Jun 05 05:50:50 <jonwil> Will do soon :)
Jun 05 06:00:41 <jonwil> Very close to having it working, just need to deal with some stuff that arises because we have out-of-date versions of a few perl modules.
Jun 05 06:18:07 <jonwil> Its currently running through the pile of OpenSSL tests
Jun 05 06:18:56 <jonwil> which, given the stuff I had to do to the Perl build system, is probably a good thing to have it do (make sure nothing is broken_)
Jun 05 06:19:10 <ceene> sounds good
Jun 05 07:18:48 <Oksana> Great
Jun 05 08:17:40 <DocScrutinizer05> \o/
Jun 05 08:19:04 <DocScrutinizer05> noob question: SSL is a layer over whatever communication (usually port80 HTTP) that basically could get implemented as a proxy on top of a regular port80 communication, right?
Jun 05 08:19:29 <DocScrutinizer05> just it usually runs on port443
Jun 05 08:20:01 <jonwil> Looks like I am hitting an issue in Scratchbox
Jun 05 08:20:36 <jonwil> Seems like if you run an armel binary inside scratchbox, the emulation layer doesn't pass the value of environment variables like LD_LIBRARY_PATH and LD_PRELOAD through to that arm binary
Jun 05 08:20:41 <DocScrutinizer05> maybe to make more clear: is it correct that you could wrap arbitrary data tarffic into a SSL layer, and HTTPS is actually HTTP wrapped in SSL
Jun 05 08:20:50 <ceene> DocScrutinizer05: basically, yeah, there's even stunnel, which is an app that does exactly that, sits between a communication channel and sets up a ssl layer around it
Jun 05 08:21:01 <jonwil> Which is why the openssl 1.1.0h test suite is failing.
Jun 05 08:21:02 <DocScrutinizer05> ceene: ta! :-)
Jun 05 08:21:16 <jonwil> And why some stuff in the Mozilla build process is failing as well
Jun 05 08:22:25 <DocScrutinizer05> jonwil: umm, quite possible
Jun 05 08:23:32 <ceene> DocScrutinizer05: you can also install telnet-ssl and telnet -z whatever 443 and manually type HTTP requests
Jun 05 08:23:47 <DocScrutinizer05> afaik scratchbox is a chroot/qemu, most likely env vars from outside get lost
Jun 05 08:25:04 <DocScrutinizer05> ceene: :-D TA! I was just confronted with "would all this HTTP based stuff also work via HTTPS?" and I said "of course, why not? As long as the port 443 is available"
Jun 05 08:25:40 <ceene> i think i may have removed the tests on my port of openssl
Jun 05 08:25:42 <DocScrutinizer05> let aside higher system load for encryption
Jun 05 08:27:31 <ceene> yep, just a layer around it
Jun 05 08:27:40 <ceene> i'm sure socat also supports ssl around whatever thing you want to run
Jun 05 08:43:50 <Maxdamantus> 20:20:42 < DocScrutinizer05> maybe to make more clear: is it correct that you could wrap arbitrary data tarffic into a SSL layer, and HTTPS is actually HTTP wrapped in SSL
Jun 05 08:44:01 <Maxdamantus> HTTP/1.1 at least, not necessarily so for HTTP/2
Jun 05 08:44:14 <Maxdamantus> since it supposedly uses that application identifier thing.
Jun 05 08:44:42 <Maxdamantus> ALPN
Jun 05 08:45:46 <Maxdamantus> Apparently required for HTTP/2
Jun 05 10:59:52 <jonwil> Still no closer to figuring out why this isn't working and because you can't debug armel binaries in SB due to qemu, I have to rely on printf debugging to narrow down the cause of the problem.
Jun 05 12:25:58 <DocScrutinizer05> well, I guess when you want to debug a process in qemu, you need to run gdb in qemu and start the process from gdb
Jun 05 12:27:01 <DocScrutinizer05> of course it makes no sense to run qemu under gdb to debug the process running inside qemu
Jun 05 12:33:55 <bencoh> indeed
Jun 05 12:34:00 <bencoh> err, wait
Jun 05 12:34:52 <bencoh> at least you could probably use the qemu debugger
Jun 05 12:35:35 <bencoh> https://en.wikibooks.org/wiki/QEMU/Debugging_with_QEMU
Jun 05 12:36:43 <DocScrutinizer05> http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Kernel_and_Debugging_Guide/Maemo_Debugging_Guide  sounds like it might be related
Jun 05 12:37:54 <DocScrutinizer05> actually http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Kernel_and_Debugging_Guide/Maemo_Debugging_Guide#Debugging_Issues_in_Scratchbox
Jun 05 15:05:55 <enyc> ooer #maemo-cssu is invite-only?!?!?
Jun 05 15:13:05 <bencoh> uh, what?
Jun 05 15:13:16 <bencoh> enyc: I know of #maemo-ssu
Jun 05 15:13:25 <bencoh> dunno about -cssu
Jun 05 15:18:10 <enyc> aaaah!
Jun 05 15:18:14 <enyc> that may by my mistook
Jun 05 16:08:48 <kalin> hi guys
Jun 05 16:09:27 <kalin> i trying to boot kubuntu mobile on my n900
Jun 05 16:11:01 <vahe> nice
Jun 05 16:11:08 <bencoh> do you have a working kernel first? or are you trying to boot a maemo kernel?
Jun 05 16:11:09 <kalin> i've downloaded image, put it to sd card with dd, installed linux power kernel boot image on n900
Jun 05 16:12:10 <kalin> now i have boot menu, but can't boot from sd
Jun 05 16:12:13 <bencoh> iirc modern libc won't work with old (<2.6.32) kernels
Jun 05 16:12:23 <bencoh> unless you patch it
Jun 05 16:12:58 <bencoh> do you get anything though? errors?
Jun 05 16:13:13 <kalin> no
Jun 05 16:13:40 <bencoh> oh, and ... to get something on screen you'd probably need kernel modules
Jun 05 16:14:06 <bencoh> (framebuffer driver and stuff, at least)
Jun 05 16:14:32 <bencoh> fbcon isn't builtin
Jun 05 16:14:55 <bencoh> (so you probably wouldn't get any on-screen console anyway)
Jun 05 16:15:54 <bencoh> If you wanna keep the maemo/power kernel I'd suggest follow one of the arch/gentoo/whatever threads on talk.maemo.org
Jun 05 16:16:31 <bencoh> if you're okay with using a mainline kernel, you might want to have a look at Leste first
Jun 05 16:16:34 <bencoh> and move from there
Jun 05 16:16:49 <kalin> i want to use some lightweght debian-like distro
Jun 05 16:17:10 <bencoh> then I'd *definitely* have a look at Leste :)
Jun 05 16:17:26 <bencoh> they're rebasing maemo bits on top of modern devuan
Jun 05 16:17:42 <plazmonii> kalin: жм?
Jun 05 16:18:55 <kalin> so how to run Leste on my n900?
Jun 05 16:20:17 <kalin> oh, i gotta fly...
Jun 05 16:20:20 <kalin> see ya
Jun 05 16:20:36 <bencoh> kalin: https://leste.maemo.org/Nokia_N900
Jun 05 16:20:57 <kalin> thanks
Jun 05 16:22:10 <sicelo> and #maemo-leste
Jun 05 16:24:13 <plazmonii> kalin: jeh, join #maemo-leste
Jun 06 01:18:18 <brolin_empey> Heh, my Galaxy Note 3 can charge from a Nokia AC to microUSB power supply but a Galaxy Nexus cannot charge from the same charger but can charge from a generic AC to USB power supply.
Jun 06 01:20:45 <brolin_empey> I guess I should buy another Samsung AC to USB power supply for around 2 CAD on eBay to leave at work because the only one I have is at home.
Jun 06 01:32:01 <brolin_empey> s/charger/power supply/
Jun 06 01:51:59 <jonwil> Still no closer to getting this damn thing working. I have ruled out LD_PRELOAD or LD_LIB_PATH being at fault (the system isn't setting LD_PRELOAD when it runs the offending binary and LD_LIB_PATH is the same at the point the binary is run and when the binary itself starts).
Jun 06 01:53:06 <jonwil> Debugging is hard because the x86 build completes correctly with no problems and debugging armel binaries in Scratchbox is too hard due to the way the whole qemu thing works
Jun 06 02:10:13 <jonwil> I uploaded what I have so far at https://github.com/jonwil/openssl if anyone wants to take a look
Jun 06 02:42:58 <Maxdamantus> you mean `LD_LIBRARY_PATH` right?
Jun 06 02:43:12 <Maxdamantus> `LD_LIB_PATH` isn't a thing afaik
**** ENDING LOGGING AT Wed Jun 06 03:00:10 2018