**** BEGIN LOGGING AT Thu Jun 08 03:00:02 2017
Jun 08 04:58:49 <Oksana> >> If you want to work with large datasets, don't load the whole thing into memory, use something like BerkeleyDB << https://stackoverflow.com/questions/1242832/in-perl-how-can-i-release-memory-to-the-operating-system
Jun 08 04:59:11 <Oksana> I think that Contacts uses BerkeleyDB (if I remember correctly)
Jun 08 04:59:36 <Oksana> Would it be relevant for el-v1.db? Would it be any better than currect Sqlite3?
Jun 08 04:59:37 <stryngs> Anyone here going to DEFCON this year?
Jun 08 04:59:51 <Oksana> Not me. I can bet it's not in Sydney.
Jun 08 05:00:11 <stryngs> Definitely Not.  Las Vegas =)
Jun 08 05:00:13 <stryngs> VIVA LAS VEGAS!
Jun 08 05:12:43 <Maxdamantus> If you're trying to make a faster alternative to grep, the re2 tools released by Russ Cox that are similar to Google codesearch might help.
Jun 08 05:14:01 <Maxdamantus> Not sure how well it does incremental updates though.
Jun 08 05:15:03 <Maxdamantus> You'd basically just treat chunks of a lareg log file as separate documents, and just unconditionally grep over the new stuff at the end that hasn't been indexed yet.
Jun 08 05:42:16 <L29Ah_> https://vc.gg/blog/so-its-been-a-while.html usa is kill
Jun 08 06:01:30 <Maxdamantus> https://github.com/google/codesearch
Jun 08 06:01:38 <Maxdamantus> The tools I'm referring to.
Jun 08 06:02:06 <Maxdamantus> (again, written by Russ Cox, who's pretty cool)
Jun 08 06:48:04 <L29Ah_> found a dead(?) n900 for $37, the seller says it starts to glow orange when plugged into a charger but won't boot
Jun 08 06:48:25 <KotCzarny> pricey
Jun 08 06:48:30 <L29Ah_> i wonder if it's the battery or it's more seriously borked hardware-wise
Jun 08 06:48:42 <L29Ah_> well, the cheapest one i could find in moscow
Jun 08 06:48:51 <L29Ah_> the working ones are twice as expensive
Jun 08 06:49:52 <L29Ah_> i could wait for a better offer but now i find myself lacking any projects to work on (and not willing to brick my main phone at the same time)
Jun 08 06:50:44 <L29Ah_> s/37/27/
Jun 08 12:15:54 <DocScrutinizer05> >>The VACUUM command may change the ROWIDs of entries in any tables that do not have an explicit INTEGER PRIMARY KEY.<< !
Jun 08 12:17:33 <DocScrutinizer05> ((<Oksana> I think that Contacts uses BerkeleyDB)) yes, that's correct
Jun 08 12:18:09 <DocScrutinizer05> however you can't switch the RDBMS behind eventslogger, since... it's a blob
Jun 08 12:19:35 <DocScrutinizer05> ((it starts to glow orange when plugged into a charger)) sounds pretty much like dead battery
Jun 08 12:19:44 <DocScrutinizer05> ~flatbatrecover
Jun 08 12:19:44 <infobot> Remove battery for 1 minute. Insert battery. Plug powered ***NOKIA WALLCHARGER*** to device. Watch steady amber. Let sit and charge. Do NOT try to boot. After 30 min, you got either a) a booted up N900, b) flashing amber which means you can boot, c) steady amber shut off -> start over again with ~flatbatrecover while already searching for a new battery. CAVEAT! Only works when ~rootfs OK (no ~bootloop)
Jun 08 12:21:06 <DocScrutinizer05> for USD 27.- you can't go wrong. Get it
Jun 08 12:25:26 <dmth|intevation> DocScrutinizer I fear L29Ah_ did not get your hint
Jun 08 12:25:57 <DocScrutinizer05> or they read the chanlog
Jun 08 12:26:07 <DocScrutinizer05> or somebody tells them when they are back
Jun 08 12:27:27 <DocScrutinizer05> ((change the ROWIDs)) this may cause worse than data loss: subtle data corruption
Jun 08 12:29:02 <DocScrutinizer05> you can't be sure Nokia didn't mess up and use row-id as a reference in their data model
Jun 08 12:31:15 <DocScrutinizer05> you *could* check the table definitions right from SQLite and make sure *all* tables have row-id as "explicit INTEGER PRIMARY KEY"
Jun 08 12:31:31 <DocScrutinizer05> I however massively doubt they do
Jun 08 12:34:35 <DocScrutinizer05> re contacts berkleydb: http://maemo.cloud-7.de/maemo5/usr/local/bin/contact
Jun 08 12:34:41 <DocScrutinizer05> it's evolution
Jun 08 12:36:35 <DocScrutinizer05> rather use http://maemo.cloud-7.de/maemo5/usr/local/bin/contact2 which I think is better than mine
Jun 08 12:42:16 <DocScrutinizer05> re el-v1.db SQL: maybe see http://maemo.cloud-7.de/maemo5/patches_n_tools/eventsdb_calllog_triggers.sh
Jun 08 12:42:39 <DocScrutinizer05> though unrelated to size, just shows some SQL for that database
Jun 08 12:49:06 <sicelo> hi. i wish to respond to a mailing list message that i was not part of. there is a mailto link on the mail archive page. is there a way i can comment from mutt?
Jun 08 12:52:07 <sicelo> i asked in #mutt, but maybe someone here knows too
Jun 08 12:52:54 <DocScrutinizer05> you need to register to the ML, I think mails form "outside" are not allowed. I guess they are kept for moderation but nobody does such moderation
Jun 08 12:53:21 <DocScrutinizer05> unless you're talking about a ML unrelated to maemo
Jun 08 12:54:28 <DocScrutinizer05> it's a question of ML administrative settings if mails form unregistered users are allowed, allowed by manual moderation, or plain discarded
Jun 08 12:55:38 <DocScrutinizer05> aaah wait, you ask for the "in-reply-to" to keep the answer within the thread?. Usually not really possible
Jun 08 12:55:54 <sicelo> yes, that's what i'm asking
Jun 08 12:56:33 <sicelo> i have message id - i think editing the mail header would do - but i don't know how
Jun 08 12:56:43 <DocScrutinizer05> keep the subject verbatim, prolly your best chance. Though some more savvy expert might know a trick
Jun 08 12:57:23 <DocScrutinizer05> yeah, editing the "in-reply-to" and "reference(?)-ID" header fields might work
Jun 08 12:58:01 <DocScrutinizer05> but you don't have those when you didn't receive the email from subscription
Jun 08 12:58:15 <DocScrutinizer05> the archives don't give them away afaik
Jun 08 12:58:41 <DocScrutinizer05> you could ask another user to forward the email to you so you could reply
Jun 08 12:59:57 <sicelo> there is (debian ML)
Jun 08 13:00:36 <sicelo> ID, that is (and of course subject) :-)
Jun 08 13:01:35 <DocScrutinizer05> my approach would be to open a reply email to an arbitrary thread in that ML (of which I actually received the emails), then view the raw text headers and try to edit the whole thing accordingly
Jun 08 13:02:28 <DocScrutinizer05> there's more than just ID header, I think it's "in-reply-to" or somesuch
Jun 08 13:02:51 <DocScrutinizer05> plus I seem to recall there is some "thread-ID" or somesuch
Jun 08 13:03:33 <DocScrutinizer05> so a canonical ML-thread-reply email has at least 3 relevant header fields
Jun 08 13:03:45 <DocScrutinizer05> pus subject
Jun 08 13:04:26 <DocScrutinizer05> no idea which majordomo or whatever that particular ML server uses and which header fields that thing needs
Jun 08 13:04:58 <DocScrutinizer05> or rather, which fields the user mail clients need ;-)
Jun 08 13:05:20 <DocScrutinizer05> it's tricky
Jun 08 13:38:34 <DocScrutinizer05> (("sqlite vacuum" - el-v1.db is 14% smaller now)) for wikiwide it should reduce size *to* <5% of current size, or it won't suffice
Jun 08 13:41:58 <DocScrutinizer05> the recommended way to handle stuff is to rename el-v1.db (after getting all the data from it that you know you want to keep for frequent access, by whatever means. Be it screenshots or pencil and paper worst case though the backup app supposed to do some mildly useful dump of the el-v1.db content). Then reboot immediately after renaming, to make the system re-create the db
Jun 08 13:44:42 <DocScrutinizer05> even better: fuser --kill -KILL path/to/el-v1.db; then reboot
Jun 08 14:26:50 <L29Ah_> dmth|intevation: i did :p
Jun 08 14:41:34 <DocScrutinizer05> good
Jun 08 14:41:58 <DocScrutinizer05> for 27 bucks you hardly get a spare digitizer
Jun 08 14:42:12 <DocScrutinizer05> tzz
Jun 08 17:22:46 <kivivi> hi
Jun 08 17:22:54 <kivivi> hello?
**** ENDING LOGGING AT Fri Jun 09 03:00:03 2017