00:06.43 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-89-102-207-166.net.upcbroadband.cz) |
00:26.37 | *** join/#maemo-ssu Estel_ (~Estel@dgn90.neoplus.adsl.tpnet.pl) |
00:51.57 | *** join/#maemo-ssu Estel^ (~Estel@dgn90.neoplus.adsl.tpnet.pl) |
02:17.22 | *** join/#maemo-ssu amiconn_ (amiconn@rockbox/developer/amiconn) |
02:20.26 | *** join/#maemo-ssu Estel_ (~Estel@dgn90.neoplus.adsl.tpnet.pl) |
03:03.59 | *** join/#maemo-ssu amiconn_ (amiconn@rockbox/developer/amiconn) |
03:04.08 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-89-102-207-166.net.upcbroadband.cz) |
03:10.51 | *** join/#maemo-ssu Estel_ (~Estel@dgf19.neoplus.adsl.tpnet.pl) |
03:18.29 | *** join/#maemo-ssu Estel_ (~Estel@dgf19.neoplus.adsl.tpnet.pl) |
03:18.31 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-89-102-207-166.net.upcbroadband.cz) |
03:44.48 | *** join/#maemo-ssu Estel_ (~Estel@dgf19.neoplus.adsl.tpnet.pl) |
03:45.50 | *** part/#maemo-ssu cbeau (~cbeau@69-165-173-117.dsl.teksavvy.com) |
03:48.13 | *** join/#maemo-ssu Estel_ (~Estel@dgf19.neoplus.adsl.tpnet.pl) |
04:38.01 | *** join/#maemo-ssu Estel_ (~Estel@dgf19.neoplus.adsl.tpnet.pl) |
05:38.55 | freemangordon | DocScrutinizer51, Pali, merlin1991: the situation is in a no way different to cbs-widget: FOSS library linked to closed source |
05:40.18 | freemangordon | and I think putting the keys (and only the keys) in a different header file, which won't be on gitorious and won't get included in tar.gz solves our problem pretty easy |
06:08.28 | freemangordon | merlin1991: here http://gcc.gnu.org/releases.html is the ling for gcc 4.6.2 source code, just follow "GCC 4.6.2" link and choose the best mirror for you |
06:08.35 | freemangordon | *link |
06:40.03 | *** join/#maemo-ssu amiconn (amiconn@rockbox/developer/amiconn) |
07:01.06 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-89-102-207-166.net.upcbroadband.cz) |
07:22.51 | Estel_ | freemangordon, may I buggy You with interesting request? |
07:23.03 | freemangordon | sure |
07:24.20 | Estel_ | do you remember idea about using Rpi as hdmi out for N900... During conversation with SpeedEvil and Hurrian, the latter come up with extra interesting idea |
07:24.20 | Estel_ | http://mg.pov.lt/maemo-irclog/%23maemo.2012-06-06.log.html#t2012-06-06T05:06:40 |
07:24.31 | Estel_ | from this line to end of related discussion |
07:25.16 | Estel_ | IMO, it's our best chance to achieve it without - practically - any overhead on N900's side (CPU, RAM), and ability mto transfer everything, using Rpi as processing machine |
07:25.51 | freemangordon | Estel_, cloning is done on a HW level |
07:25.53 | Estel_ | and, as my limited knowledge goes implementing it *shouldn't* be very hard, given fact, that TV-Out kernel module is open and we need only small change + implement it to userland as additional option |
07:25.58 | Estel_ | he? |
07:26.03 | freemangordon | driver os FOSS (DSS2 driver) |
07:26.08 | Estel_ | SpeedEvil suggested, that hardware element read framebuffer |
07:26.11 | Estel_ | yea |
07:26.14 | Estel_ | and it compress etc |
07:26.21 | Estel_ | read on, I proposed other way later |
07:26.32 | Estel_ | SpeedEvil was in soubt, if it's doable using USb speeds, but it was confirmed later |
07:27.02 | freemangordon | and it supports VFI (virtual framebuffer), not sure is it enabled in .config |
07:27.07 | Estel_ | basically, something that would allow Rpi to read our framebufer - in raw mode - and process it on Pi |
07:27.12 | Estel_ | hm, itneresting |
07:27.47 | Estel_ | it would be 800x480*3*FPS bits - for 10 fps, it's only ~11Mb/s, would run flawlessly even over wifi |
07:27.57 | Estel_ | on good connection wifi, it should work even for 20 and 30 FPS |
07:28.12 | Estel_ | for USB, it would be possible to use higher resolutions |
07:29.09 | Estel_ | Pi would need to, basically, display captured framebuffer, without or with additional processing |
07:29.36 | Estel_ | this way, everything would work, even video, and - except dropping to framebuffer like in Tv-out - everything would be processed using Pi resources |
07:30.10 | Estel_ | I knwo You're (both) overprojected, but it would be KILLER feature - better than anythinbg made for any mobile device without hdmi out, including apples and paid software |
07:30.51 | Estel_ | of course You know my limited (barely existent) skills re coding, but as far as I can tell, the bets thing is that it *shouldn't* require cosmic ammounts of effort |
07:30.55 | Estel_ | teases |
07:31.04 | Estel_ | ~tease |
07:31.09 | Estel_ | ~striptease |
07:31.09 | infobot | Hoogah Hoogah wah wah *takes of the box* *dances around showing of the cpu and memory* Ah yeah you likey my little HD no? |
07:36.18 | freemangordon | Estel_, scratch that, what is supported is RFBI, not VFI |
07:36.46 | *** join/#maemo-ssu dafox (~dafox@dyn-194208.nbw.tue.nl) |
07:45.29 | freemangordon | Estel_, I am not sure I get the idea. You want to use VENC (that is TV out) module to do what exactly? |
07:46.07 | Estel_ | to cannibalsie way it's reading screen data *before* processing via hardware parts... |
07:46.40 | Estel_ | and to change tv-out applet to generl purpose external view applet (or better name) that have tv-out as one of, lets say 3 functions. or two |
07:47.18 | Estel_ | then, on Raspberry Pi side, capture screen data (in form it is presented before processed by N900 hardware tv-out) and display it via HDMI |
07:47.22 | freemangordon | Estel_, there is no dedicated TV out memory, fremebuffer is read line by line and scaled in real-time |
07:47.23 | Estel_ | = HDMI output |
07:47.29 | Estel_ | OK |
07:47.38 | Estel_ | so couldn't it by read line by line over USB networking by Pi? |
07:47.47 | Estel_ | is there a way to allow Pi to access N900's framebuffer? |
07:47.51 | Estel_ | so scratch tv-out module |
07:47.59 | Estel_ | if it's not needed, then, even better |
07:48.06 | Estel_ | we don't need scalling |
07:48.17 | Estel_ | only exporting data to framebuffer, in native resolutions, for beginning |
07:48.22 | freemangordon | to access as in? it is /dev/fbN (n=0,1,2) |
07:48.27 | Estel_ | any sensible way to read it from another linuxbox? |
07:48.46 | Estel_ | Ok, do we have any implementations in linux world, where something read framebuffer and display it? |
07:48.47 | freemangordon | ya, do a netcat :P |
07:49.02 | Estel_ | as per my calculations, bits per second are |
07:49.11 | Estel_ | 800*480*3*FPS |
07:49.18 | freemangordon | wrong |
07:49.20 | Estel_ | ? |
07:49.36 | freemangordon | we are not using rgb, |
07:49.42 | Estel_ | ops |
07:49.48 | freemangordon | FB is 16 bpp |
07:49.50 | Estel_ | don't tell me that it's 16 bits :p |
07:49.56 | Estel_ | eh |
07:50.04 | freemangordon | 565 or something |
07:50.15 | Estel_ | and we have this pout into framebuffer, without any drawback for performance, when using tv-out? |
07:50.19 | Estel_ | I don't talk about scaling |
07:50.32 | Estel_ | oh god |
07:50.35 | freemangordon | please rephrase |
07:50.39 | Estel_ | any way to process it in sensible way before sending? |
07:50.47 | freemangordon | process as in? |
07:51.04 | Estel_ | I jsut wonder how Tv-out is processing so much raw data, even if we drop scaling to Pal/NTSC |
07:51.07 | freemangordon | comress? scale? |
07:51.18 | Estel_ | IDK, change to RGB, whatever |
07:51.21 | freemangordon | Estel_, you annot drop the scaler |
07:51.26 | freemangordon | *cannot |
07:51.34 | freemangordon | it is a part of VENC module |
07:51.47 | Estel_ | understood. |
07:51.54 | freemangordon | Estel_, look at DSS subsystem in TRM and you will get the picture |
07:51.58 | Estel_ | so after reading from framebuffer, it's either PAL/NTSc or nothing? |
07:52.10 | Estel_ | i mean tv-out of course |
07:52.18 | freemangordon | it is 565 |
07:52.40 | freemangordon | which is passed to VENC module in chunks of (iirc) 2048 bytes |
07:52.42 | Estel_ | it doesso 800*480*565*FPs, which make it unsuitable for sending |
07:53.24 | freemangordon | Estel_, that is the FB content, not the result of downscaling |
07:53.24 | Estel_ | now, I wonder if we can process it a little - in any way - to make it "smaller" in terms of byte,s without using too much resources on N900 side, and, actually, leave considerable ammount for other functions |
07:53.30 | Estel_ | yea |
07:53.41 | Estel_ | but we *don't* want to downscale for HDMI out |
07:53.46 | Estel_ | for that we have Tv-out |
07:53.49 | freemangordon | MJPEG? |
07:53.58 | freemangordon | or some other fast algo |
07:54.17 | Estel_ | sounds ncie. Basically, main limit is *realistic* thoroghput of USB networking |
07:54.39 | Estel_ | ...and mjpeg would allow us to do 20 fps without killing N900? |
07:54.39 | freemangordon | BTW I still wonder what is wrong with X forwarding |
07:55.00 | Estel_ | freemangordon, remember thread in TMO? AFAIK, You were able to forward EasyDebian to external machine... |
07:55.04 | Estel_ | but not Maemo as per se |
07:55.11 | freemangordon | never tried hard |
07:55.12 | Estel_ | lack of xephyr or something |
07:55.22 | freemangordon | it was just a POC |
07:55.32 | Estel_ | You know, if You would try hard, and it would succeed, it would be same *killer* feature with even less hassle ;) |
07:55.46 | Estel_ | for sure less than RE fb plugin :P |
07:55.48 | Estel_ | teases again |
07:55.58 | freemangordon | why you would want maemo through HDMI? |
07:56.05 | freemangordon | it won't fit |
07:56.26 | freemangordon | most of the UI is optimized (read hardcoded) fro 800x480 |
07:56.28 | freemangordon | *for |
07:56.35 | Estel_ | because I would like to sue higher resolutions for 3rd party FOSS programs (i.e. not hildon-desktop itself) |
07:56.52 | Estel_ | because Tv output is downscaled and small fonts are hard to read |
07:57.13 | freemangordon | example? ED? |
07:57.26 | freemangordon | ED works like charm with X forwarding |
07:57.28 | Estel_ | because I love to work on trips with N900, but hate fact that quality of everything I see on big screen is worse than holding small screen close to eyes :P |
07:57.38 | Estel_ | no no,m lets leave debian alone |
07:58.01 | freemangordon | but what application then, gimme an example |
07:58.13 | Estel_ | basically, any FOSS program in repos that could run it higher ress but is hardcoded now to 800x480 could be updated to work using other resolutions |
07:58.28 | Estel_ | leafpad :P |
07:58.33 | Estel_ | no, seriously |
07:58.56 | Estel_ | I'm afraid to tell "games", bnecause I will hear "then do it Yourself and don't bug me" |
07:59.01 | Estel_ | but, other than games: |
07:59.34 | freemangordon | Estel_, have in mind that even if there is a way to forward FB to Pi, what you would yse as an inout device? |
07:59.45 | freemangordon | n900 itself? |
08:00.13 | freemangordon | *input |
08:00.29 | freemangordon | is afk |
08:00.58 | Estel_ | sorry, got dced |
08:01.24 | Estel_ | freemangordon, other than some educational tools, videos and images Document viewers? |
08:01.39 | Estel_ | Ed doesn't have DSP acceleration for video, at least not the easy way |
08:01.55 | Estel_ | BTW, AFAIK, in your testing Ed was exported to external screen via LXDE, yep? |
08:02.19 | Estel_ | some programs are veryt resource hungry, and run better when started from within Maemo, without LXDE and all middle-mans (GIMP) |
08:02.33 | Estel_ | (Chromium, even old Libre Office) |
08:02.39 | Estel_ | s/old/good old/ |
08:02.44 | Estel_ | but generally, You're right |
08:02.53 | Estel_ | most programs we need in better resolution are in ED |
08:03.11 | Estel_ | if we can't run hildon-desktop and so goes on in higher resolutions, it may be quite unnecessary, for sure |
08:03.35 | Estel_ | honestly, i'm a little pissed off by PAL/NTSC downscaling |
08:04.12 | Estel_ | it's just quite annoying, that on big big BIG screen, You have lower resolution/quality of image than on native 800x480 screen,, but maybe it's only psychological/purist point of view |
08:04.36 | Estel_ | but, another *important* thing - other systems, like Ubuntu 12.04. should it work just like with Easy Debian? |
08:04.59 | Estel_ | Your's and other's experiences show, that running programs from such antively booted systems is much faster than chroot (why, BTW?) |
08:05.22 | Estel_ | I think that they should be exportable via xephyr etc, but You know better, probably |
08:05.36 | Estel_ | (i.e. confirm/deny? tried that? interested to try?) |
08:11.40 | freemangordon | Estel_, forget about streaming media from n900 to Pi, OMAP has one GFX and 2 video overlays which are scaled/mixed in HW to produce the image you have on LCD |
08:12.00 | Estel_ | ah |
08:12.24 | Estel_ | <PROTECTED> |
08:12.44 | Estel_ | downscaling to PAL (little better) or NTSC (little worse) is irritating, but we can live with it |
08:12.56 | Estel_ | and question about other systems booted independently of Maemo? |
08:13.07 | Estel_ | I suspect it should be no problem to send them? |
08:13.30 | freemangordon | and that is done with export DISPLAY=a.d.c.d:0.0 startlxde |
08:13.52 | freemangordon | Estel_, NFC, but it should be the same |
08:14.25 | Estel_ | I think You agree that it's very interesting thing for, lets say, Lubuntu 12.04 |
08:14.37 | Estel_ | especially, considering how fast things like Chromium or LibreOffice works there |
08:14.48 | freemangordon | no, that was for ED chroot |
08:14.54 | Estel_ | BTw, any clue why it works much slowe rin chroot under Maemo? chroot should be like native speed? |
08:15.23 | freemangordon | slower? no, it is the same here, but my ED is on uSD |
08:15.40 | freemangordon | and not in a loopback device |
08:15.49 | Estel_ | same here, no loopback |
08:15.56 | Estel_ | but in eMMC. i use swap; on uSD... |
08:16.05 | freemangordon | me too |
08:16.12 | Estel_ | hey, I'm sure i remember You saying, on ubuntu 12.04 thread, that things work faster than in ED |
08:16.35 | freemangordon | hmm, can't remember saying such thing |
08:16.45 | Estel_ | hm, shouldn't we avoiud I/O conflicts with swap, just like with Maemo on eMMC? ED during operation, also generates quite ammount of I/O, doesn't it conflict with swap I/O? |
08:16.57 | freemangordon | seems like no |
08:17.00 | Estel_ | ok, will search and ask later, maybe ti was just me missunderstanding it |
08:17.28 | Estel_ | sorry for bugging You then, and thanks for clarification |
08:17.39 | Estel_ | You're right, it seems, that we have everything we need possible already |
08:28.40 | *** join/#maemo-ssu dafox (~dafox@dyn-194208.nbw.tue.nl) |
08:45.26 | freemangordon | MohammadAG: hiding FB secret key is enough, ain't? API key is useless without it, correct? |
08:52.45 | *** join/#maemo-ssu arcean (~arcean@aafr39.neoplus.adsl.tpnet.pl) |
08:55.59 | MohammadAG | No |
08:55.59 | MohammadAG | FB secret key is used for more advanced changes |
08:55.59 | MohammadAG | Or calls |
08:55.59 | MohammadAG | Anyway, why hide it when it's clear in the public? |
09:22.43 | *** join/#maemo-ssu Pali (~pali@unaffiliated/pali) |
09:24.00 | freemangordon | MohammadAG: so I should remove API key from the sources too? |
09:24.25 | freemangordon | it does not make sense, sekret key is used fro signature generation |
09:24.33 | freemangordon | *secret |
09:25.23 | MohammadAG | Dude? Just keep it |
09:25.24 | MohammadAG | Just keep both keys |
09:25.25 | MohammadAG | The same way everyone keeps them |
09:25.39 | freemangordon | MohammadAG: where it is clear? in binary? |
09:26.20 | MohammadAG | Yes |
09:26.37 | MohammadAG | You can't do anything harmful with them |
09:26.51 | freemangordon | MohammadAG: what one can do with API key only? |
09:27.02 | MohammadAG | Nothing |
09:27.11 | freemangordon | ok, that was my question :) |
09:27.25 | MohammadAG | So just keep the API key and the secret key in the source |
09:27.25 | DocScrutinizer51 | those keys are just so FB stays in control in case somebody comes up with a rogue app |
09:27.50 | freemangordon | so, now we have API key(only) on gitorious, secret key is not there |
09:27.54 | MohammadAG | Exactly, they can just delete/blacklist the key |
09:27.59 | MohammadAG | WHY?! |
09:28.07 | freemangordon | just in case |
09:28.16 | freemangordon | to keep merlin1991 happy :D |
09:28.23 | DocScrutinizer51 | weird rationale |
09:28.35 | freemangordon | ? |
09:29.02 | freemangordon | one needs both keys to be able to send a request to FB servers |
09:29.43 | MohammadAG | In case what |
09:29.45 | MohammadAG | Very weird |
09:29.46 | MohammadAG | Nokia made no effort to hide |
09:29.48 | MohammadAG | Neither should they make any effort |
09:29.49 | MohammadAG | A request to do what |
09:29.51 | MohammadAG | Just put both keys on gitorious |
09:29.52 | MohammadAG | They won't cause a nuclear strike |
09:30.49 | MohammadAG | If you're not putting it on gitorous I am |
09:31.07 | freemangordon | ok, application id (API key) is visible from your FB profile |
09:31.36 | MohammadAG | Again any argument you make won't make sense |
09:31.48 | MohammadAG | Both keys can be obtained by stringing the lib |
09:32.02 | MohammadAG | Both keys aren't tied in any way to a certain device's imei |
09:32.06 | freemangordon | MohammadAG: but it is not that easy to have the lib |
09:32.11 | MohammadAG | Both keys are in plaintext |
09:32.14 | DocScrutinizer51 | that's what Pali ans I say whole morning |
09:32.46 | freemangordon | and the concern is that FB could blacklist n900 if we put the keys on gitorious |
09:32.56 | MohammadAG | FB don't give a fuck |
09:33.02 | DocScrutinizer51 | the ONLY issue / concern being it's part of Nokia (C) IP |
09:33.21 | MohammadAG | That's false, I can bet on it |
09:33.44 | freemangordon | TBH I am ok either ways |
09:33.55 | DocScrutinizer51 | unless we use our own key, which kinda defeats purpose of 100% compatibility |
09:34.28 | freemangordon | MohammadAG: just make and agreement with merlin1991 and i will put secret key on gitorious too |
09:34.36 | freemangordon | ok? |
09:34.51 | Pali | freemangordon, my idea was to include key in hex form like: char key[] = { 0x11, 0x12, ... }; |
09:35.01 | DocScrutinizer51 | again. please ask Quim! |
09:35.02 | freemangordon | Pali, it is in such form |
09:35.07 | Pali | it is same as hexfump of elf binary |
09:35.44 | freemangordon | https://gitorious.org/community-ssu/feedservice-plugin-fb-common/blobs/master/include/facebook/common.h#line29 |
09:35.58 | DocScrutinizer51 | If Quim gives OK, we *are* OK and basically Nokia's agent |
09:36.19 | DocScrutinizer51 | in that regard |
09:36.45 | freemangordon | hmm, or not :) |
09:43.42 | MohammadAG | iOS keys are also plaintext |
09:44.03 | freemangordon | MohammadAG: where? |
09:44.09 | freemangordon | you have the source code? |
09:46.26 | MohammadAG | No, strings |
09:46.42 | MohammadAG | No one hides these |
09:47.07 | MohammadAG | You can get the N9 keys in the sane way |
09:54.51 | freemangordon | MohammadAG: lets end that discussion, I told you, make an agreement with merlin1991 and I will but the second key on gitorious too, ok? |
09:55.27 | freemangordon | *put |
10:02.04 | freemangordon | MohammadAG: on the other hand - were you able to find X-Fade? |
10:02.29 | freemangordon | merlin1991 told me there is some problem with -testing repo |
10:03.18 | *** join/#maemo-ssu xmlich02 (~imlich@2001:67c:1220:80c:d6:202c:d9a0:3d9c) |
10:03.52 | MohammadAG | merlin1991's pestering him afaik |
10:14.53 | *** join/#maemo-ssu int_ua (~int_ua@ip-602f.proline.net.ua) |
10:20.49 | *** join/#maemo-ssu MohammadAG (~MohammadA@ool-45772b34.dyn.optonline.net) |
10:21.20 | *** join/#maemo-ssu xnt14 (~xnt14@ool-45772b34.dyn.optonline.net) |
10:30.53 | *** join/#maemo-ssu lizardo (lizardo@nat/indt/x-vpkkogbsedoumsbj) |
10:32.08 | *** join/#maemo-ssu MohammadAG (~MohammadA@Maemo/community/contributor/MohammadAG) |
11:16.23 | Estel_ | freemangordon, MohammadAG, if some contact with X-Fade is needed, You can always ask me |
11:16.44 | Estel_ | i'm in almsot constant contact with him (no joke :D ) |
11:17.49 | Estel_ | ...so I can easily forward Your problems. Generally, anyone from council is good to ping regarding infra |
12:05.49 | Pali | Estel_, promoting package kernel-power-settings to extras: http://maemo.org/packages/view/kernel-power-settings/ |
12:06.31 | Estel_ | yea, told X-Fade about that one |
12:06.34 | Estel_ | he is working on it |
12:06.41 | Estel_ | You remind me old problem, or something new failed? |
12:06.53 | *** join/#maemo-ssu DocScrutinizer06 (~HaleBopp@openmoko/engineers/joerg) |
12:06.58 | *** join/#maemo-ssu DocScrutinizer (~halley@openmoko/engineers/joerg) |
12:08.08 | Estel_ | Pali^^^ |
12:08.23 | Pali | old problem |
12:20.26 | *** join/#maemo-ssu maemobot (~Estel@dgf19.neoplus.adsl.tpnet.pl) |
12:22.27 | *** join/#maemo-ssu lizardo_ (~lizardo@189.2.193.178) |
12:24.13 | *** join/#maemo-ssu arcean (~arcean@aafr39.neoplus.adsl.tpnet.pl) |
14:38.01 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-89-102-207-166.net.upcbroadband.cz) |
16:18.52 | *** join/#maemo-ssu NIN101 (~NIN@p5DD28769.dip0.t-ipconnect.de) |
16:23.03 | *** join/#maemo-ssu mirandir (~valentin@lec67-4-82-230-53-23.fbx.proxad.net) |
16:42.09 | DocScrutinizer51 | hmm |
16:42.57 | DocScrutinizer51 | that might explain a lot :-P |
16:43.57 | DocScrutinizer51 | alas if it's really a bot, it will blow each turing test outa the water |
16:44.39 | DocScrutinizer51 | by simply redefining the test parameters radically |
17:14.43 | *** join/#maemo-ssu Atarii (~Atarii@77.107.156.213) |
17:14.44 | *** join/#maemo-ssu Atarii (~Atarii@unaffiliated/atarii) |
17:18.37 | *** join/#maemo-ssu krayon (~krayon@ppp118-209-144-84.lns20.mel6.internode.on.net) |
17:18.44 | *** join/#maemo-ssu krayon (~krayon@pdpc/supporter/28for7/krayon) |
17:27.25 | *** join/#maemo-ssu arcean_ (~arcean@aacx75.neoplus.adsl.tpnet.pl) |
17:31.17 | DocScrutinizer51 | turing redefined: if tester headbangs before 15min are over, obviously bot wins |
17:32.29 | DocScrutinizer51 | other forms of giving up count as well: going insane, shoot yourself... |
17:35.18 | DocScrutinizer51 | shoot the bot/non-bot... |
17:35.50 | DocScrutinizer51 | well, in thois latter case it's arguable if the bot won |
17:36.21 | merlin1991 | headdesks |
17:36.46 | merlin1991 | which sane person timestamps deltas with the beginning of the delta? |
17:37.07 | freemangordon | merlin1991, hi |
17:37.14 | freemangordon | read the log? |
17:37.32 | merlin1991 | just did, sry I actually wanted to pester x-fade today but didn#t manage |
17:38.01 | freemangordon | ok, as I was under the impression that you told meyesterday it is mag who is pestering X-Fade |
17:38.02 | DocScrutinizer51 | merlin1991: lol |
17:38.32 | merlin1991 | nah I wanted todo that myself |
17:38.48 | freemangordon | the second think - I uploaded FB crap on gitorious with only one of the two keys :) |
17:38.58 | DocScrutinizer51 | sure thing, keep the fun for yourself ;-zp |
17:39.00 | freemangordon | a kind of compromise :D |
17:39.37 | freemangordon | but mag wants them both. please, do some agreement with him and tell me what to do |
17:39.43 | freemangordon | merlin1991 ^^^ |
17:39.54 | merlin1991 | jsut load the 2nd one |
17:40.07 | freemangordon | upload the second one on gitorious? |
17:40.08 | freemangordon | ok |
17:40.09 | merlin1991 | I'm the minority in here saying no so I guess I'm overruled |
17:40.15 | DocScrutinizer51 | could any of you guys please ask quim?! |
17:40.44 | freemangordon | DocScrutinizer51: I can bet qgil has NFC about FB API and keys |
17:40.57 | DocScrutinizer51 | I'd rather trust in his decision on it |
17:41.29 | freemangordon | But qhat kind of decisiion one can make if he is not informed on the matter at all? |
17:42.01 | DocScrutinizer51 | he for sure has an idea of API access keys in general |
17:42.57 | freemangordon | DocScrutinizer51, I have move than idea for security, keys and such (that is a part of my job). But it does not mean I know a shit about FB |
17:43.28 | *** join/#maemo-ssu int_ua (~int_ua@ip-602f.proline.net.ua) |
17:43.51 | DocScrutinizer51 | it's not FB which is the problem here, it's a key handed out to NOKIA by FB |
17:43.54 | freemangordon | It is MohammadAG that is the most knowledgeable, so maybe we should trust him |
17:44.18 | freemangordon | and that key flls under the TC of FB, not Nokia |
17:44.21 | freemangordon | *falls |
17:44.45 | freemangordon | as it is FB who is the key issuer and SP |
17:44.46 | DocScrutinizer51 | I'd trust him if we hadn't that debate and 'minority report' |
17:45.04 | freemangordon | we have the debate because we lack knowledge |
17:45.21 | freemangordon | and it is the same for qgil |
17:45.21 | DocScrutinizer51 | and it is NOKIA wo owns the key |
17:45.32 | freemangordon | no, it is FB who owns the key |
17:45.44 | DocScrutinizer51 | not at all |
17:45.47 | *** join/#maemo-ssu mase76 (~mase76@p5DD3A7B7.dip.t-dialin.net) |
17:45.51 | freemangordon | want a bet? |
17:45.57 | DocScrutinizer51 | evidence: it's in a nokia blob |
17:46.13 | freemangordon | but it is authourized by FB, not Nokia |
17:46.34 | DocScrutinizer51 | that's nothing to do with ownership |
17:47.26 | freemangordon | DocScrutinizer51, it has all to to with the ownership, it is the same if you say that you are owner of the public key in an RSA pair |
17:47.41 | freemangordon | the owner is the issuer |
17:47.44 | DocScrutinizer51 | itMs NOKIA who's responsible to obey the EULA for that ke |
17:47.46 | freemangordon | not the user |
17:47.48 | DocScrutinizer51 | key |
17:48.20 | DocScrutinizer51 | rabulism |
17:48.28 | freemangordon | but it is the user who will be declined access to FB with that key (if FB decides) not Nokia |
17:48.43 | freemangordon | and that is the poit |
17:48.43 | DocScrutinizer51 | ask quim, instead of speculating |
17:48.49 | freemangordon | *point |
17:49.06 | DocScrutinizer51 | handwaving |
17:49.15 | freemangordon | [20:38] <freemangordon> DocScrutinizer51: I can bet qgil has NFC about FB API and keys |
17:49.30 | DocScrutinizer51 | so what |
17:49.46 | DocScrutinizer51 | search somebody to hol.d the bet or what? |
17:50.02 | DocScrutinizer51 | I'm not interested |
17:50.11 | DocScrutinizer51 | I know quim some time |
17:50.30 | DocScrutinizer51 | and it's irrelevant what he got a clue of or not |
17:50.42 | DocScrutinizer51 | asking him is the only PC thing |
17:51.20 | freemangordon | well, I would like to know what merlin1991 and mag will decide |
17:51.36 | DocScrutinizer51 | they already did |
17:51.37 | freemangordon | qgil is not a CSSU maintainer last time I chacked |
17:51.42 | freemangordon | *checked |
17:51.53 | freemangordon | so, I will upload the second key |
17:52.00 | freemangordon | gtg |
17:52.04 | freemangordon | bye for now |
17:53.14 | mase76 | hi! does anybody know, if openmediaplayer reads the gain tagged with mp3gain? |
18:06.12 | merlin1991 | bah |
18:06.16 | merlin1991 | was just about to answer |
18:06.29 | merlin1991 | (close to om uses mafw thus NO!) |
18:11.27 | Sc0rpius | man |
18:11.54 | Sc0rpius | do you know if there's a way to make the middle top button (the one that unlocks the screen) behave EXACTLY like the one at the side ? |
18:12.22 | Sc0rpius | because my side button (the one that slides) is so worn that it's hard for me to slide it anymore |
18:12.41 | Sc0rpius | and the button that unlocks (but then swipe) is totally useless!!! I would love to make it unlock/lock the screen without sliding shit |
18:13.02 | Sc0rpius | I guess there's a way since there are people that have made custom screensavers or something. |
18:18.24 | DocScrutinizer06 | in former times my advice would've been "delegate it to the council, they'll feature it out" - nowadays it seems in sovjet russia out of features councils your delegation |
18:19.47 | DocScrutinizer06 | anyway fact is we're redistributing non-foss stuff owned by Nokia, even if we change that key. This means we ought talk to them prior to doing so |
18:20.15 | DocScrutinizer06 | change the notation of that key (to ocatl for example) |
18:20.19 | DocScrutinizer06 | octal |
18:22.45 | DocScrutinizer06 | yet another point nobody mentioned yet: only Nokia (and FB, but they won't) can tell if that key FB granted usage to Nokia actually runs under same TOS like the ones somebody (merlin?) quoted here |
18:23.47 | DocScrutinizer06 | their "contract" might differ vastly from what you find on FB's webpage for end users and other ants |
18:26.53 | DocScrutinizer06 | Sc0rpius: straight brute force approach: redefine GPIO numbers in kernel |
18:28.06 | DocScrutinizer06 | but that might fail, as... I mean it's the *power* button, not some arbitrary switch like camdoor or kbd-slider |
18:28.55 | DocScrutinizer06 | it's probably as nasty as redefining ctrl-alt-del for ISA |
18:28.59 | Sc0rpius | hmm |
18:29.07 | Sc0rpius | well I would want to unlock/lock the screen with single push |
18:29.22 | Sc0rpius | and a long push to be the power button just like it is now but without showing menu or annoying swipe screen |
18:29.32 | DocScrutinizer06 | how about fixing the slider ? |
18:30.06 | Sc0rpius | I would need another button, I've slided too much and the little bar is flat so the whole button is flat |
18:30.28 | DocScrutinizer06 | a long push to power button does (TZZZDUM) power off |
18:30.40 | Sc0rpius | yeah that's fine. |
18:30.46 | Sc0rpius | but I would like to redefine the short push |
18:30.57 | Sc0rpius | to lock/unlock without annoyances |
18:31.12 | DocScrutinizer06 | the short push also does power off, though with an option for software to intercept |
18:31.47 | DocScrutinizer06 | it's a quite special kind of button |
18:32.08 | Sc0rpius | well I saw an application in tmo these days |
18:32.49 | Sc0rpius | I forgot the name |
18:33.08 | DocScrutinizer06 | I'd get a spare part for the slider button |
18:33.21 | Sc0rpius | QtLockScreen |
18:33.34 | Sc0rpius | I guess the guy that wrote it somehow intercepted the button |
18:33.37 | Sc0rpius | and the whole thing actually |
18:33.48 | Sc0rpius | he made a video |
18:33.51 | Sc0rpius | http://www.youtube.com/watch?v=hUK7OvJZGdo |
18:34.21 | Sc0rpius | I should test his application first since it doesn't have a slide (but it has a button) |
18:34.25 | Sc0rpius | and then read his source code |
18:34.25 | DocScrutinizer06 | no, it's probably low level maemo (even kernel) that intercepts it |
18:34.48 | DocScrutinizer06 | the higher level stuff prolly will use dbus to learn about power button pressed |
18:35.08 | Sc0rpius | well but he definitely made it |
18:35.38 | DocScrutinizer06 | well sure, you can replace what's there and already doing it by some own stuff |
18:36.10 | DocScrutinizer06 | but I guess it's easy to make it behave exactly like the lockslider |
18:36.18 | DocScrutinizer06 | it's NOT easy |
18:36.48 | DocScrutinizer06 | honestly, why don't you fix the friggin plastic lever |
18:36.55 | Sc0rpius | and where I can find a new one |
18:36.57 | DocScrutinizer06 | or get a spare |
18:37.14 | Sc0rpius | the N900 has been discontinued for so long |
18:37.20 | Sc0rpius | it's very hard to find replacements for it |
18:37.23 | DocScrutinizer06 | I could dremel one for you, from solid gold ;-D |
18:37.41 | Sc0rpius | hehehehe |
18:38.02 | DocScrutinizer06 | or just glue a layer of solid gold handle on top of the worn plastic |
18:39.25 | DocScrutinizer06 | wonders what users do to lockslider, as Sc0rpiusisn't the only one with exactly this problem |
18:43.53 | Sc0rpius | that's the ONLY hardware button I use |
18:44.01 | Sc0rpius | everytime I check my phone I slide it |
18:44.10 | Sc0rpius | that's like 129035468912346589127364981273465 times a day |
18:48.20 | *** join/#maemo-ssu xnt14 (~xnt14@ool-45772b34.dyn.optonline.net) |
18:48.50 | *** join/#maemo-ssu MohammadAG (~MohammadA@ool-45772b34.dyn.optonline.net) |
18:49.01 | DocScrutinizer06 | sure thing, nevertheless this plastic lever has to be a defective part as well |
18:49.33 | DocScrutinizer06 | otherwise I can't see how anybody except Krueger would ruin it by operating it |
19:03.53 | DocScrutinizer06 | except of course when dust and fine sand blocks the slide |
19:05.04 | DocScrutinizer06 | anyway, looking at it I think you even can drill a 1mm hole into it ans screw a knob on top |
19:05.08 | DocScrutinizer06 | and* |
19:05.13 | *** join/#maemo-ssu MohammadAG (~MohammadA@Maemo/community/contributor/MohammadAG) |
19:06.58 | DocScrutinizer06 | or glue a 0.8mm steel bolt into the 1mm hole, with a nice round end that just protrudes 1.5mm over the flat surface of the bump sliding in the hole |
19:07.10 | *** join/#maemo-ssu trbs (~trbs@2001:470:d2ad:1:4a5b:39ff:fe7d:1623) |
19:07.38 | DocScrutinizer06 | s/in the hole/in the case apperture/ |
19:10.05 | MohammadAG | <freemangordon> It is MohammadAG that is the most knowledgeable, so maybe we should trust him |
19:10.07 | MohammadAG | hmm? |
19:39.22 | *** join/#maemo-ssu int_ua (~int_ua@ip-602f.proline.net.ua) |
19:55.12 | *** join/#maemo-ssu int_ua (~int_ua@ip-602f.proline.net.ua) |
21:41.50 | *** join/#maemo-ssu wmarone (~wmarone@c-67-174-151-253.hsd1.ca.comcast.net) |
21:47.47 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-89-102-207-166.net.upcbroadband.cz) |
21:53.21 | freemangordon | MohammadAG: we were discussing those keys again |
21:53.47 | freemangordon | and AFAIK you're the author of sociality :P |
21:57.41 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
21:59.52 | MohammadAG | I didn't read facebook's TOS |
21:59.57 | MohammadAG | but based on many facebook apps |
22:00.06 | MohammadAG | including the keys as plaintext is not a problem |
22:00.16 | MohammadAG | Jaffa did it with Hemres |
22:00.23 | MohammadAG | official facebook apps do it |
22:00.52 | MohammadAG | any changes that can cause a malicious attack need the password of the developer |
22:01.02 | MohammadAG | which I recall was a user on facebook called Maemo Farchild |
22:01.19 | freemangordon | See. That is why I said you're the most knowledgeable amongst us ;) |
22:01.26 | freemangordon | On that matter |
22:02.10 | freemangordon | anyway, will upload second key tomorrow (if have time) |
22:02.41 | freemangordon | merlin1991 ^^^ |
22:03.21 | freemangordon | merlin1991, you fixed that libstdc++ problem ain't? |
22:03.28 | merlin1991 | yeah |
22:03.35 | freemangordon | and i see libgcc1, why is that? |
22:03.46 | merlin1991 | I did nothing like that |
22:03.51 | freemangordon | Raimu reported something? |
22:03.57 | MohammadAG | 169795223032197 |
22:03.57 | MohammadAG | a642f00d2e84cffba72432d0911cfe02 |
22:04.00 | MohammadAG | N9 ^ |
22:04.03 | MohammadAG | they're plaintext too |
22:04.40 | freemangordon | hmm, I see libgcc1 as an update when i do apt-get upgrade, could it be that meego backporting efforts? |
22:04.44 | freemangordon | MohammadAG: ok |
22:04.49 | MohammadAG | https://api.facebook.com/method/facebook.mailbox.send <-- I FOUND IT |
22:05.31 | freemangordon | WTF is that? |
22:05.47 | MohammadAG | the method to send a message on facebook |
22:05.56 | MohammadAG | private API, I wonder how that would work |
22:06.00 | freemangordon | aah, ok. congrats :P |
22:06.10 | freemangordon | now you will add chat to sociality? |
22:06.18 | MohammadAG | chat is simple XMPP |
22:06.20 | Raimu | freemangordon, what's up? |
22:06.26 | MohammadAG | Simple XMPP isn't simple for me :p |
22:06.51 | freemangordon | Raimu, I was wondering how that thumb2 thingie is developing on your side :) |
22:07.06 | Raimu | Oh, yeah, the presencevnc thing. |
22:07.26 | DocScrutinizer06 | it's not about plaintext, it's about our policy to (not?) redistribute Nokia stuff that's not clearly FOSS |
22:07.45 | freemangordon | Raimu: did you find why it does not start? |
22:08.04 | freemangordon | (or whatever the problem was) |
22:08.31 | Raimu | freemangordon: Some googling suggested there's some "symbol" it cannot locate in the thumbed libraries. |
22:08.46 | Raimu | Try installing it on your machine. It plays nice. :) |
22:09.23 | freemangordon | Raimu: sorry, I did not investigate it here, this FB shit had wasted all my time these days |
22:09.30 | freemangordon | plays nice? |
22:09.49 | freemangordon | BTW which symbol? |
22:09.50 | freemangordon | and which .so |
22:09.51 | Raimu | By "plays nice" I mean it doesn't fsckup your maemo. Anyway, run using terminal ("presencevnc"), enter any IP in the address box and try to connect. It blasts a symbol error in the terminal and dies. |
22:10.25 | freemangordon | Raimu: ^^^ |
22:10.28 | Raimu | Lessee. Damn, I didn't scrawl the error message. |
22:10.45 | freemangordon | ;( |
22:11.03 | Raimu | I'm a bit busy, but I'll get back to you with the program. |
22:11.04 | freemangordon | btw what that application does? |
22:11.12 | Raimu | It's a VNC client/viewer. |
22:11.23 | Raimu | You can view remote desktops through it. |
22:11.32 | freemangordon | hmm, so I am supposed to have VNC server on my desc? |
22:11.38 | Raimu | Nope. |
22:11.43 | freemangordon | aah, ok |
22:11.49 | Raimu | It crashes without even getting to the connection. |
22:12.04 | Raimu | Just the moment it tries to do something with the IP you gave it dies. |
22:12.37 | freemangordon | Raimu: ok, going to install it |
22:12.53 | Raimu | Thanks. Let's see if it's just something really messed up on my accord. |
22:14.13 | freemangordon | Raimu: could you give me the exact command? |
22:15.11 | freemangordon | presencevnc: symbol lookup error: presencevnc: undefined symbol: _ZN7QString8vsprintfEPKcPv |
22:15.41 | freemangordon | hmm, something with Qt, WTF? |
22:16.37 | freemangordon | Raimu: it is not thum,b2 itself, for some reason gcc 4.6.2 has messed up Qt's QString, will check that |
22:17.17 | merlin1991 | ^^ epic |
22:17.45 | Raimu | That's it. |
22:20.11 | freemangordon | aaah, now i remember, there was a warning, that there is a chage in vargarg between gcc a.b.c and x.y.z, could be that, will ask ggole for a solution :D |
22:20.18 | freemangordon | *change |
22:20.58 | freemangordon | hmm, seems I have to take some rest :D |
22:21.48 | freemangordon | my typing skills are bellow zero |
22:21.51 | freemangordon | *below |
22:23.24 | merlin1991 | agreed ;) |
22:23.45 | Raimu | Rest well. |
22:23.53 | DocScrutinizer06 | try LD_BIND_NOW=y |
22:24.17 | freemangordon | DocScrutinizer06: ? |
22:24.41 | DocScrutinizer06 | >>Anyway, run using terminal ("presencevnc"), enter any IP in the address box and try to connect. It blasts a symbol error in the terminal and dies. |
22:25.03 | DocScrutinizer06 | LD_BIND_NOW=y presencevnc(?) |
22:25.38 | DocScrutinizer06 | throws unknown-symbol errors during load time, not during runtime |
22:29.02 | DocScrutinizer06 | of course unless you do dynamic loading of libs under user control |
22:30.26 | DocScrutinizer06 | man linux-ld |
22:30.37 | DocScrutinizer06 | err man ld-linux |
22:32.34 | DocScrutinizer06 | btw seems you just found one of the reasons why you generally don't change buildtool chain for a distro |
22:33.00 | DocScrutinizer06 | I mean for one rev of a distro |
22:33.53 | DocScrutinizer06 | possible change in symbol naming just one reason |
22:34.43 | DocScrutinizer06 | world has seen a lot of other more subtle issues that caused severe headache from time to time |
22:35.31 | DocScrutinizer06 | generally the ABI isn't guaranteed to always stay compatible |
22:37.02 | freemangordon | guys, i really gtg, will someone continue the conversation on #maemo, seems there is another application broken by libcurl3 |