**** BEGIN LOGGING AT Sat Jan 02 02:59:59 2016
Jan 02 08:36:00 <jonwil> hi
Jan 02 08:50:35 <brolin_empey> jonwil: ’lo.
Jan 02 11:53:20 <freemangordon> Pali: what about something like http://pastebin.com/TF8ywZAq
Jan 02 11:53:42 <freemangordon> the only problem is that events are registered with a delay, but I guess this can be fixed
Jan 02 11:57:42 <Pali> freemangordon: looks good
Jan 02 11:57:51 <Pali> only one problem is in ALS_PATH_RX51_3x
Jan 02 11:58:14 <Pali> path via i2c-adapter is not stable
Jan 02 11:58:25 <freemangordon> yeah, I forgot I touched that one too. But anyway, ^^^ is just POC
Jan 02 11:58:31 <freemangordon> I know
Jan 02 11:58:44 <Pali> there should be more stable symlink in /sys somewhere
Jan 02 11:58:54 <freemangordon> Pali: any clue why events might come delayed? the way mce sets giomonitor?
Jan 02 11:59:17 <Pali> first check that kernel does not delay them
Jan 02 11:59:29 <freemangordon> where?
Jan 02 11:59:42 <Pali> use e.g. program input-events
Jan 02 11:59:44 <freemangordon> evtest spits them immediately
Jan 02 11:59:49 <Pali> ok
Jan 02 12:00:01 <Pali> then it is somewhere in mce..
Jan 02 12:00:01 <freemangordon> anyway, have to leave now, will look at the issue later
Jan 02 12:00:07 <freemangordon> yes, something in mce
Jan 02 12:00:12 <freemangordon> bb for now
Jan 02 12:00:12 <Wizzup> How much are they delayed?
Jan 02 12:00:29 <freemangordon> hard to say, but more than a second
Jan 02 12:00:56 <freemangordon> also, it is not the same everytime
Jan 02 12:35:49 <Oksanaa> I think that khweeteur does not bother to rm cache-avatars (up to 20MB) from home/user when being purged-uninstalled. Anybody up to confirming-denying?
Jan 02 13:04:50 <DocScrutinizer05> man apt
Jan 02 13:30:59 <DocScrutinizer05> it's of course arguable if those avatar files are really 'config data'
Jan 02 13:31:41 <kerio> they're not
Jan 02 13:31:46 <DocScrutinizer05> but I think the general take on this is "never delete anything from user's home"
Jan 02 13:32:19 <kerio> the cache should really not be in /home/user though
Jan 02 13:32:32 <kerio> i guess that storing it in MyDocs becomes complicated, however
Jan 02 13:35:06 <DocScrutinizer05> how so?
Jan 02 13:35:42 <kerio> MyDocs gets unmounted at the user's will
Jan 02 13:35:50 <DocScrutinizer05> yeah
Jan 02 13:36:01 <kerio> stupid decisions all around, really
Jan 02 13:36:40 <DocScrutinizer05> well, that's the sort of compromises you need to do when you got only 240MB of /
Jan 02 13:36:53 <Djgio07> HI
Jan 02 13:37:21 <DocScrutinizer05> though ~optification is really a headache
Jan 02 13:38:19 <DocScrutinizer05> when the avatar data is no user's config data then it belongs into /opt
Jan 02 13:39:00 <DocScrutinizer05> at least on a genuine maemo5 system
Jan 02 13:39:30 <DocScrutinizer05> and yes, it should get cleaned out then
Jan 02 13:39:55 <DocScrutinizer05> "forgot to clear the cache" sounds like a common mistake
Jan 02 13:41:19 <DocScrutinizer05> or at your discretion s/cache/tmp/
Jan 02 13:56:56 <KotCzarny> one another thing to consider, with generic inputs/gpio, one could try redefining other button/event source (to unlock the screen for example)
Jan 02 13:57:32 <KotCzarny> or to redefine depending what is running etc
Jan 02 13:57:55 <KotCzarny> with hardcoded settings there is no such flexibility
Jan 02 14:40:29 <freemangordon> KotCzarny: why is that? We can always introduce switch<->functionality mapping file
Jan 02 14:40:37 <freemangordon> or gconf or whatever
Jan 02 14:47:29 <Pali> freemangordon: how hard would be to fix dsp driver and include it again into upstream kernel?
Jan 02 14:47:49 <Pali> you already played with that code, so maybe you could know...
Jan 02 14:54:18 <freemangordon> Pali: they want remoteproc driver. and that wouldn;t be easy
Jan 02 14:54:52 <freemangordon> i'll need remoteproc coff fw loader and who knows what else
Jan 02 14:54:56 <freemangordon> *it'll
Jan 02 15:28:17 <Pali> freemangordon: what is remoteproc?
Jan 02 15:28:43 <freemangordon> Pali: https://www.kernel.org/doc/Documentation/remoteproc.txt
Jan 02 15:31:49 <Pali> ufff
Jan 02 15:32:39 <Pali> now last version of tidspbridge cannot be compiled anymore (on uptream kernel)...
Jan 02 15:33:11 <freemangordon> :(
Jan 02 15:36:49 <Pali> in old TODO for tidspbridge is nothing about remoteproc
Jan 02 15:37:08 <Pali> there is just: DOFF binary loader: consider pushing to user space
Jan 02 15:37:32 <Pali> only *consider*
Jan 02 16:01:50 <freemangordon> Pali: ok, it turned out some timeout exists in mce re misc input devices, I added a new "class" switch devices with all callbacks etc and now unlocking, slide etc is instant
Jan 02 16:02:36 <Pali> freemangordon: ok
Jan 02 16:07:32 <freemangordon> Pali: https://github.com/community-ssu/mce/commit/a3f25c56d7f57af5fc5a9c4c375b0db624f70b53
Jan 02 16:09:38 <Pali> ok
Jan 02 16:10:08 <Pali> now I'm looking at mce/modules/vibrator.c and this code is not compatible with upstrem kernel too...
Jan 02 16:10:29 <Pali> path /sys/class/i2c-adapter/i2c-1/1-0048/twl4030_vibra/pulse does not exist
Jan 02 16:10:42 <freemangordon> vibrator is exported via evdev as well
Jan 02 16:10:49 <Pali> looks like that upstream kernel export twl4030 via input layer too!
Jan 02 16:11:36 <Pali> and twl4030-vibra is registered under audio device
Jan 02 16:12:32 <freemangordon> just a second do boot
Jan 02 16:15:09 <freemangordon> Pali: http://pastebin.com/itKGCpMK
Jan 02 16:15:49 <Pali> EV_FF
Jan 02 16:15:54 <freemangordon> yes
Jan 02 16:15:59 <freemangordon> force-feedback
Jan 02 16:16:22 <Pali> but problem is that event5 name is not stable
Jan 02 16:16:29 <freemangordon> so what?
Jan 02 16:16:30 <Wizzup> use by-id or by-path
Jan 02 16:16:38 <freemangordon> no by-id
Jan 02 16:16:40 <freemangordon> :)
Jan 02 16:16:41 <Wizzup> Or is that not available?
Jan 02 16:16:43 <Wizzup> Yeah, that
Jan 02 16:16:49 <Pali> need to match against "Input device name" (which is "twl4030:vibrator")
Jan 02 16:16:59 <Wizzup> Pali: ls /dev/input/by-id :) 
Jan 02 16:17:02 <freemangordon> Pali: we can add another class
Jan 02 16:17:16 <Pali> or maybe just "*:vibrator"
Jan 02 16:17:16 <freemangordon> the same way I did for switches
Jan 02 16:17:30 <freemangordon> Pali: no, we'd rather mach on EV_FF
Jan 02 16:17:33 <freemangordon> *match
Jan 02 16:17:36 <freemangordon> instead of a name
Jan 02 16:17:49 <freemangordon> I was thinking the same for gpio-keys
Jan 02 16:17:53 <Pali> Wizzup: no by-id in Maemo :-(
Jan 02 16:18:19 <Pali> freemangordon: yes, match against EV_FF could work too
Jan 02 16:18:24 <freemangordon> to parse supported keys/switches and to choose what we need
Jan 02 16:18:46 <Pali> $ ll /sys/class/input/input*/capabilities/ff
Jan 02 16:18:58 <Pali> freemangordon: that match is really easy ^^^
Jan 02 16:19:00 <freemangordon> hmm, no there is evdev ioctl for that
Jan 02 16:19:17 <Pali> ok
Jan 02 16:19:24 <freemangordon> as we can get the supported buttons as well
Jan 02 16:22:16 <Wizzup> getting the name is EVIOCGNAME
Jan 02 16:23:58 <freemangordon> Wizzup: seems you know evdev, could you write a function that gets "/dev/input/eventX", event types and buttons to match and returns fd if those match?
Jan 02 16:24:15 <Wizzup> yes
Jan 02 16:24:19 <freemangordon> great
Jan 02 16:24:39 <Wizzup> C, right?
Jan 02 16:24:43 <freemangordon> yep
Jan 02 16:24:50 <Wizzup> will do
Jan 02 16:24:56 <freemangordon> thanks!
Jan 02 16:25:12 <Wizzup> do you want to match against something hardcoded?
Jan 02 16:25:20 <Wizzup> (I guess so?)
Jan 02 16:25:23 <freemangordon> Wizzup: BTW, can we disable some of the keys via evdev interface?
Jan 02 16:25:31 <freemangordon> no hadcoded
Jan 02 16:25:36 <freemangordon> a parameters
Jan 02 16:26:01 <freemangordon> like match("/dev/input/event1", EV_KEY
Jan 02 16:26:02 <Wizzup> input devices are immutable, what can be done is grabbing the device (being the sole program to get the events), making a new input device, and filtering certain events
Jan 02 16:26:11 <freemangordon> oops
Jan 02 16:26:17 <freemangordon> ...
Jan 02 16:26:22 <Wizzup> match(file, EV_KEY, KEY_A) ?
Jan 02 16:26:33 <freemangordon> yes
Jan 02 16:26:38 <Wizzup> sure
Jan 02 16:26:49 <freemangordon> but 2 and 3 parameters should be arrays IMO
Jan 02 16:27:14 <freemangordon> or somesuch
Jan 02 16:27:29 <Wizzup> ack
Jan 02 16:27:30 <freemangordon> to be able to match both EV_SW and EV_KEY, for example
Jan 02 16:27:46 <freemangordon> with apprpriate masks for keys and switches
Jan 02 16:27:48 <Wizzup> I would say that param 2 should not be - since EV_SW cannot have KEY_A for example
Jan 02 16:27:53 <Wizzup> well, I guess that is possible though
Jan 02 16:27:57 <Wizzup> just needs to be well defined/clear :) 
Jan 02 16:28:22 <freemangordon> haveing integer array as a second and third parameter should do the job
Jan 02 16:28:33 <freemangordon> {EV_KEY, EV_SW, -1}
Jan 02 16:28:33 <Wizzup> ack.
Jan 02 16:28:49 <freemangordon> and array of integer arrays for the third
Jan 02 16:29:56 <freemangordon> {{KEY_A, KEY_B, -1},{SW_KEYPAD_SLIDE,  SW_CAMERA_LENS_COVER, -1}};
Jan 02 16:30:03 <freemangordon> Wizzup: ^^^
Jan 02 16:32:58 <Wizzup> Ack
Jan 02 16:37:36 <Wizzup> will need like 30 mins.
Jan 02 16:38:06 <freemangordon> no hurry
Jan 02 16:55:45 <Pali> freemangordon, Wizzup: there is sysfs entry for disabling: /sys/class/input/input*/device/disabled_keys /sys/class/input/input*/device/disabled_switches
Jan 02 16:55:55 <freemangordon> Pali: I know
Jan 02 16:56:22 <freemangordon> the point is that it would have been easier if we could do it via evdev interface
Jan 02 16:56:55 <Pali> but this is specific for gpio-keys.ko driver :-(
Jan 02 16:57:04 <Wizzup> Pali: ah, tmyk
Jan 02 16:57:10 <Wizzup> ah, right.
Jan 02 16:57:20 <freemangordon> Pali: yes, exactly
Jan 02 16:58:27 <Pali> gpio-keys.ko support it only via sysfs
Jan 02 16:59:18 <Pali> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/input/keyboard/gpio_keys.c#n58
Jan 02 17:02:22 <freemangordon> yeah
Jan 02 17:26:03 <Wizzup> freemangordon: http://sprunge.us/BJdY?c something like this
Jan 02 17:26:24 <Wizzup> the defines at the top of the function are taken from evtest
Jan 02 17:30:16 <Wizzup> ah - there is a bit more I have to clean up
Jan 02 17:30:19 <Wizzup> stray call that is not required
Jan 02 17:33:59 <Wizzup> http://sprunge.us/baKa?c should do it
Jan 02 17:45:47 <Wizzup> removed extra q = 0; -> http://sprunge.us/ZVfM?c
Jan 02 18:00:17 <Wizzup> the NULL is not required in the key_keys arg
Jan 02 18:37:09 <DocScrutinizer05> chem|st: xes: warfare: why does tmo block *reading* visitors?
Jan 02 18:37:30 <DocScrutinizer05> >>Sorry, it seems that you are using an IP address or a proxy that is listed in the forum anti spam blacklist.<<
Jan 02 18:37:53 <DocScrutinizer05> how would a visitor spam the forum?
Jan 02 18:40:01 <DocScrutinizer05> I haven't checked this yet (I can't tbh, wrong unblocked IP) but reports from Hellekin suggest the forum spits out that error message quoted above for visitors simply trying to read an arbitrary post like http://talk.maemo.org/showthread.php?p=1492838
Jan 02 19:14:55 <freemangordon> Wizzup: thanks; will look at later
Jan 02 19:15:07 <Wizzup> no rush
Jan 02 19:23:08 <DocScrutinizer05> xes: warfare: chem|st: I'd think DoS by unregistered visitors would get blocked by traffic shaping or fail2ban, access to login page by fail2ban or vbulletin internal means when number of failed tries per time from one IP fail, and only access to registration page needs spam-list blocking. No?
Jan 02 19:31:50 <DocScrutinizer05> "sorry, Tor users are not allowed to *read* this forum" is silly
Jan 02 19:36:48 <DocScrutinizer05> I can see how Tor is prolly used by spammers to write posts, but it is also used by the most privacy and security aware legit users to _read_ tmo. The latter shouldn't get blocked
Jan 02 19:37:55 <DocScrutinizer05> no read access should get blocked, only write access
Jan 02 19:38:27 <DocScrutinizer05> (except in case of [D]DoS)
Jan 02 19:43:16 <DocScrutinizer05> hmm, possibly another 'user' (actually bot) used same Tor exit node to brute-force try to register to tmo. So the only feasible way to block this is to ban the tor node IP, assuming our infra blocks on firewall level this would result in such effect
Jan 02 19:51:08 <bencoh> +1 for read-access
Jan 02 20:06:31 <Pali> freemangordon: new version of module-init-tools is in cssu-devel, now modprobe should take params also from kernel cmdline
Jan 02 20:34:24 <DocScrutinizer05> warfare: xes: assuming IP filtering is done on firewall, we need a "RPC-channel" from tmo engine to the firewall to add 'offender IPs'
Jan 02 20:36:40 <DocScrutinizer05> tmo engine should only blacklist actual offenders, not do a preemptive block of whole RMBs
Jan 02 20:38:23 <DocScrutinizer05> IOW the attack detection must run on tmo, only the teckling of tagged offenders may happen on firewall. And FW should automatically clean out expired IPs from block table after some relatively short period (24h?)
Jan 02 20:58:42 <freemangordon> Pali: good
Jan 02 20:58:46 <warfare> DocScrutinizer05: The IP Filter is implemented in Apache and pulls a stop-forum-spam list. Only blocking registration and/or posting might pose a bit difficult. 
Jan 02 20:59:30 <freemangordon> Pali: coiuld you upgrade to -rc7, to see if net bug is still there? If it is, I'll try to bisect
Jan 02 20:59:44 <DocScrutinizer05> warfare: I see
Jan 02 21:00:42 <DocScrutinizer05> warfare: a tad cumbersome for innocent users only wanting to read a post and getting rejected just because they have the wrong IP
Jan 02 21:01:18 <warfare> DocScrutinizer05: yes, definitely. Maybe there is some anti-spam support in vbulletin.
Jan 02 21:01:25 <DocScrutinizer05> maybe we need a read-only mirror without filtering ;-)
Jan 02 22:08:12 <xes> DocScrutinizer05: warfare: hi! Vbullettin has antispam modules that fail very very often
Jan 02 22:21:03 <xes> if one ip is in our blacklist it means that it's been reported for malicious activity. I have checked almost every complaint and there was a real plausible reason for the presence in the list. So, in that list there aren't "innocent" users. Which is the purpose to grant a read only access to these bots and spammers?
Jan 02 22:25:20 <xes> since the blacklist has been applied, i can remember <10 spam posts. When there was only the vbullettin antispam .... well, ask the numbers to the moderators
Jan 02 22:36:39 <DocScrutinizer05> xes: what about Tor nodes?
Jan 02 22:36:53 <DocScrutinizer05> and huge NATted networks
Jan 02 22:39:46 <xes> DocScrutinizer05: do you know which kind of traffic is generated by tor?
Jan 02 22:40:03 <DocScrutinizer05> all sorts of traffic are routed via tor
Jan 02 22:40:39 <DocScrutinizer05> yes, probably a lot of spammers use tor as well. But also absolutely innocent users do
Jan 02 22:41:30 <xes> sure. One you have a minute compare the tor exit nodes list with the list of recent attacks on the web
Jan 02 22:41:42 <DocScrutinizer05> I don't know traffic _generated_ by tor though. Except of course between tor nodes
Jan 02 22:42:33 <xes> anyway, i can see how this solution is far from perfection (if a perfection exists)
Jan 02 22:42:42 <DocScrutinizer05> Tor is basically a NAT service, at least as seen from the outside
Jan 02 22:44:02 <xes> but we need an efficient solution that vbulletin addons can't provide
Jan 02 22:44:06 <DocScrutinizer05> there are other NAT that have a very huge userbase behind them. GPRS cellular serices come to mind, and in some eastern-european countries it seems even wired internet is fed through a NAT
Jan 02 22:46:13 <DocScrutinizer05> I can see a very simple 10-liner "addon" to handle this: on register page check IP of current user against RBL IP list. If match, send that IP to FW for blocking
Jan 02 22:46:19 <xes> yes, i know
Jan 02 22:46:42 <kerio> "eastern-european"
Jan 02 22:46:56 <kerio> one of the major italian ISPs does carrier-grade NAT
Jan 02 22:47:06 <DocScrutinizer05> hmm dunno, kerio. That's what I seem to remember
Jan 02 22:47:17 <kerio> no i mean
Jan 02 22:47:20 <kerio> you don't have to go that far
Jan 02 22:47:24 <DocScrutinizer05> ok
Jan 02 22:47:28 <kerio> G8 country
Jan 02 22:47:37 <kerio> carrier-grade NAT on a major wired ISP
Jan 02 22:47:46 <warfare> kerio: most major german cable providers do this.
Jan 02 22:48:09 <kerio> i think that verizon in the US does nat64 on the phones
Jan 02 22:52:57 <DocScrutinizer05> how about giving my 10-liner idea a shot?
Jan 02 23:04:38 <DocScrutinizer05> tmo could even report each IP accessing the login page, and FW does the lookup in the RBL and adds the IP to netfilter only when it's a hit in RBL
Jan 03 00:41:19 <Wizzup> freemangordon: minor cleanup http://sprunge.us/jBCN?c
**** ENDING LOGGING AT Sun Jan 03 02:59:58 2016