IRC log of #maemo for Monday, 2017-02-27

*** louisdk has quit IRC00:03
*** xy2_ has quit IRC00:22
*** slice has quit IRC00:22
*** ravelo_ is now known as ravelo00:34
*** ravelo has quit IRC00:34
*** ravelo has joined #maemo00:34
*** shentey_ has quit IRC00:55
*** M4rtinK has quit IRC01:17
*** atk has quit IRC02:00
*** atk has joined #maemo02:00
*** norayr has joined #maemo02:17
*** Pali has quit IRC02:24
*** florian has quit IRC02:34
*** sunshavi has quit IRC04:09
*** heroux has quit IRC06:01
*** lxp has joined #maemo06:01
*** lxp1 has quit IRC06:04
*** heroux has joined #maemo06:16
*** heroux has quit IRC06:20
*** pagurus has quit IRC07:07
*** DocScrutinizer05 has quit IRC07:09
*** DocScrutinizer05 has joined #maemo07:09
*** pagurus has joined #maemo07:14
*** esaym153 has quit IRC07:39
*** arcean has joined #maemo08:03
*** norayr has quit IRC08:28
*** L29Ah has quit IRC08:54
*** dafox has joined #maemo08:58
*** dafox has quit IRC09:28
*** jskarvad has joined #maemo09:36
*** jskarvad has quit IRC09:36
*** jskarvad has joined #maemo09:36
KotCzarnywth. o.O09:49
KotCzarnyi've started oscp on terminal, switched virtual console, it steals usb keyboard somehow anyway09:50
KotCzarnybut it might be something quirky with the keyboard itself as it's not working properly no matter if oscp is running or not09:50
Vajb_well, one can never know what those closed blobs do.09:53
KotCzarnyfunny thing is it never acted that way, it's only when i connected this new kb09:54
*** dmth|intevation has joined #maemo09:54
KotCzarnykb itself registers twice09:56
*** esaym153 has joined #maemo10:14
*** florian has joined #maemo10:19
*** florian has quit IRC10:19
*** florian_kc has joined #maemo10:20
*** florian_kc is now known as florian10:20
KotCzarnyahahah, so it finally happened10:23
KotCzarnySorry, it seems that you are using an IP address or a proxy that is listed in the forum anti spam blacklist.10:23
KotCzarnysolution in my case was just reconnecting the modem ;)10:28
KotCzarnybam! antispam subversed! ;010:29
*** vectis3 has quit IRC10:33
*** geaaru has joined #maemo10:58
*** KotCzarny has quit IRC11:08
*** KotCzarny has joined #maemo11:16
DocScrutinizer05tracker? DIE!11:40
infobot""Tracker currently has a function called tracker_memory_setrlimits() which sets the limitation of RLIMIT_AS and RLIMIT_DATA clamping it between 50% of total memory and MAXLONG (2GB on 32-bit) as an upper limit.""   Between 50% and MAXLONG of memory? WHAT THE F*CKING HELL SUCKER?!
DocScrutinizer05also tracker concept is a fail in my book11:44
DocScrutinizer05gnome mindset idiocy11:44
DocScrutinizer05why the hell would we need a database that acts like a virtual filesystem? we got a *real* filesystem for that11:46
*** N-Mi has quit IRC11:47
DocScrutinizer05OOH NO SYMLINKS on VFAT? aaaw! then use a *decent* filesystem instead? And do sorting of files by semantic properties on a file system level when storing the files, NOT on open-for-read via an abomination called tracker that makes your system explode11:48
DocScrutinizer05tracjker is basically same bullshit like akonadi and I can't help but suspect they soon get merged and then assimilated by systemd11:52
*** vectis3 has joined #maemo11:54
*** M4rtinK has joined #maemo11:58
DocScrutinizer05I *think* it should be feasible to follow the approach of: 1) spot which (core) apps actually use tracker 2) for those few that do and are not FOSS _and_ are really needed it might be very simple to write a tracker API shim that e.g. for Gallery simply delivers a `ls -l $photodir` as result of the tracker query that the Gallery does. Same for mediaplayer (though we already can rule MP out sinve we have a FOSS re-implementation and it12:01
DocScrutinizer05doesn't really *need* tracker anyway since there are already filesystem UIs for the stock MP): return `ls -l $MUSIC` instead of that tracker database crap as result to the MP tracker query12:01
*** N-Mi has joined #maemo12:03
*** N-Mi has joined #maemo12:03
*** ecloud has quit IRC12:04
*** sunshavi has joined #maemo12:06
KotCzarnyor just f*ck the media library and have some quick folders defined12:09
KotCzarnybecause really, gallery usually only needs camera folder12:10
KotCzarnyand maybe user defined folder too12:10
KotCzarnyand thumbnails could be generated on browse (assuming new files would be found)12:10
*** ecloud has joined #maemo12:14
DocScrutinizer05aka >>simply delivers a `ls -l $photodir` as result<<13:18
DocScrutinizer05so yep13:18
DocScrutinizer05prolly rather `ls -lR ...`13:18
DocScrutinizer05I always called it a major BUG in gallery that you can't separate your private from your business photos (or whatever categories make sense to you, think pr0n or holiday or sekrit-project or...)13:21
DocScrutinizer05with a shim you could simply pop up a requester asking user which category (or categories) they want to browse13:22
DocScrutinizer05I think with mount(8) namespaces and dbus trickery this shouldn't be too hard to implement without patches to any system infra or any apps13:24
DocScrutinizer05mount namespaces to enable a unique session dbus interface13:25
DocScrutinizer05rather unique dedicated session dbus, to be more precise13:25
DocScrutinizer05dbus aiui can do a lot of fancy stuff, but what it totally fails at is implementing a filter intercepting dbus signals/msgs to/from a particular app to arbitrary other dbus clients. You need two segregated bus instances for that, so mount namespaces for the dbus socket or whatever it is13:27
DocScrutinizer05the tracker API is dbus13:28
DocScrutinizer05*maybe* a LD_PRELOAD Gallery could work too, instead of running a separate dbus instance in its own namespace13:30
DocScrutinizer05note that this is only needed to fix the above mentioned BUG by allowing an executable interfacing between Gallery and generic dbus to open up a requester and modify dbus messages accordingly. Unrelated to replacing tracker dbus client by a massively simplified dummy that simply does a `ls` instead of that database foo tracker does13:33
DocScrutinizer05theoretically such requester could also live in the tracker-dummy itself, allowing users to modify the response (actually the dir(s) used) the tracker-dummy returns to a particular request like "gimme all the photos you know of"13:36
DocScrutinizer05I wouldn't even be too averse against the tracker-dummy using some optimizations like e.g. crating ,directory files, like a lot of other apps do to speed up stuff13:38
infobotDocScrutinizer05 meant: I wouldn't even be too averse against the tracker-dummy using some optimizations like e.g. creating ,directory files, like a lot of other apps do to speed up stuff13:39
*** jonwil has quit IRC13:52
*** mp107 has joined #maemo13:56
*** M4rtinK has quit IRC13:59
KotCzarnytracker's cache shoulddnt live inside target dirs14:20
KotCzarnyi would hate such trash autogeneratod14:20
jon_ythumbs.db everywhere14:22
*** juiceme has quit IRC14:39
*** juiceme has joined #maemo14:39
*** juiceme is now known as Guest4001614:39
*** Gadgetoid has quit IRC14:40
*** Gadgetoid has joined #maemo14:42
*** dmth|intevation1 has joined #maemo14:48
*** dmth|intevation has quit IRC14:48
*** florian_kc has joined #maemo15:26
*** florian has quit IRC15:27
*** florian has joined #maemo15:27
*** mp107 has quit IRC15:29
*** M4rtinK has joined #maemo15:30
DocScrutinizer05I for sure prefer a 'cache' that's simple to validate by comparing the .directory mtime to the dir's mtime, and any such 'cache' getting moved in and out and around with the directory it belongs to. Also it's just a cache and the app using it can easily do without it so user can have a config option to allow or forbid those .directory files. Not a huge issue. Original tracker OTOH... don't get me started, rather check for yourself what15:33
DocScrutinizer05gets autogenerated and when by it15:33
*** M4rtinK has quit IRC15:39
LjLi understood some of them words Doc used16:14
DocScrutinizer05LjL: can I help?16:22
LjLno it's fine, i was just bemusing on the fact i could barely understand what you said :)16:23
DocScrutinizer05well, so maybe I can actually help16:23
DocScrutinizer05tracker is a PoS, almost everybody agrees. The idea is to maybe completely drop it and replace it by a slim re-implementation that doesn't use a 1BG size mysqlite database but actually simply sends a directory listing to the app that inquires tracker info16:25
LjLall i know is every "tracker"-style thing i've ever used on any OS has always just seemed to get in the way of stuff that needed processing time and fill up my disk!16:25
DocScrutinizer05yes :-)16:25
bencohDocScrutinizer05: the thing is a directory listing without cache would be a pain as well16:26
LjLfor a short while it seemed we would all quickly be moving to database-inspired, "tagged" or whatever, filesystems16:26
LjLi think that whole part of hypothetical computing history has been erased from the books out of shame...16:26
KotCzarnyn900 is from 200916:26
DocScrutinizer05and for example Gallery app on maemo actually doesn't need to know about every photo in random places on your system. Much better it only shows content of one or two dedicated directories, and for that it doesn't need the original tracker bloat16:26
KotCzarnydeveloped from 2007-200816:26
KotCzarnyso 10 year old tech16:27
DocScrutinizer05bencoh: why?16:27
bencohDocScrutinizer05: well, depends on how recursive you want to be and how many files you have there16:27
DocScrutinizer05yeah, for ... sorry phonecall16:27
KotCzarnyit should only cache thing that got browsed, dont overdo, cache is good, preemptive cache is overengineering on limited resources device16:28
DocScrutinizer05yeah, for music it might get tricky, though ... it won't take longer than a ls -lR - for pictures it's a nobrainer I guess, except maybe for the thumbnails16:41
DocScrutinizer05I think thumbnails should get stored in the directory where the pictures are, not in a database anywhere16:42
DocScrutinizer05if only for sanity of usecase "uSD"16:43
DocScrutinizer05see (random example) which got generated by a konqueror plugin and stores thumbnails locally, so every app (not only those using tracker) can profit and the thumbnails are automatically included when the dir with the pictures gets moved/renamed or storage removed completely16:46
DocScrutinizer05IroN900:~# time ls -lR /home/user/MyDocs/allofmp3/ |wc -l16:51
DocScrutinizer05real    0m0.922s16:51
DocScrutinizer05user    0m0.148s16:51
DocScrutinizer05sys     0m0.391s16:51
DocScrutinizer05I honestly don't think tracker is faster16:52
enycWondering: will Stretch libc6 (and everything else!!!) likely be persuadable to work on 2.6.28 kernel as was the case with jessie chroot ''backporting'' ??16:58
*** L29Ah has joined #maemo17:06
bencohI guess so17:08
enycbencoh: whyso?17:11
* freemangordon doubts17:12
freemangordonDocScrutinizer05: IMO having thumbnails auto-generated int the same directory as pictures is a very bad idea - it uses space not meant for it, it changes directory layout, etc17:13
freemangordonalso, how would  that work for remote FSs?17:13
peetahhello, happily coming back to n900 after 3 years, and I try to keep up to date with what could have changed17:15
freemangordonnot that I like tracker that much, but having stuff stored in a DB placed where it should be is way better than doing ls every time.17:15
freemangordonpeetah: WB17:15
peetahfreemangordon: thanks :)17:16
peetahas a starter, is there any XMPP client supporting OMEMO ?17:16
bencohenyc: because I might be wrong, but I don't think other hard kernel dependencies were added to glibc17:18
*** ecc3g has quit IRC17:19
*** ecc3g has joined #maemo17:23
freemangordonWizzup: hi! any progress with devuan-maemo packages?17:32
Wizzupyes and no. I've been waiting on the amprolla changes required to autobuild the packages, but nextime is not particularly reachable, so parazyd has said he'll make the changes required for us to be able to do autobuilds17:35
WizzupI also spoke to parazyd about perhaps just running our own amprolla for now, and what that would entail, so we can at least build packages SOMEWHERE17:35
Wizzupthat's where the discussion stranded saturday or sunday I believe17:36
parazydi'm releasing a new distro tomorrow so i'm caught up with that17:36
parazydafterwards i'll start hacking on amprolla17:36
freemangordonok, great17:37
parazydWizzup: fwiw, a separate amprolla instance will have to be running for maemo anyway17:37
parazydand as far as i see it's not quite heavy software17:37
DocScrutinizer05freemangordon: where else do you store thumbnails for remote filesystems? locally, forever? Not at all?17:38
parazydfor the beginning i'll just try to do the bare minimum so we get it as fast as we can17:38
parazyd(get it up and running)17:38
freemangordonparazyd: do we have the needed HW?17:38
*** xy2_ has joined #maemo17:39
parazydi believe so17:39
DocScrutinizer05also WHAT about >>having stuff stored in a DB placed where it should be is way better than doing ls every time<<17:39
freemangordonparazyd: ok17:39
DocScrutinizer05this doesn't even make any sense17:39
freemangordonDocScrutinizer05: yes, it makes, imagine DB in /var which is on NAND compared to uSD flash17:40
DocScrutinizer05you're aware that tracker as well needs to "do ls every time" since it can't know if local db is up to date?17:40
freemangordonafaik it doesn't work like that17:40
freemangordonit "monitors" the needed dirs17:40
freemangordonand receives signal on change17:41
DocScrutinizer05it basically does, on top of an abomination made from scan-at-boot and inotify17:41
freemangordonyes, but this is one time only17:41
DocScrutinizer05err aha17:41
freemangordonalso, about remote dirs - no, there is no need to store the data forever17:42
freemangordonthe point is - you can;t simply write some garbage (thumbnails) on a remote FS17:42
DocScrutinizer05honestly when you want data stored, store them where they belong: on storage aka filesystem, not in a database that holds info for files a million miles away17:43
freemangordonthis feels so wrong that I can't even explain why :)17:43
DocScrutinizer05no, tracker feels so wrong that no words can describe it17:43
freemangordonDocScrutinizer05: also, imagine every OS writes its own thumbnails - soon there will be no place for pictures ;)17:44
DocScrutinizer05every OS???17:44
DocScrutinizer05dafaq how many OS you want to run on your N900?17:44
*** florian_kc has quit IRC17:45
freemangordonDocScrutinizer05: what about uSD used to store music, videos and picures?17:45
*** florian has quit IRC17:45
freemangordonit might as well be put in an android phone, connected to my PC running Ubuntu,c connected to Windoze PC, etc17:45
DocScrutinizer05also please never mind remote fs and other bizarre niche usecases, we are talking about N900 system and MyDocs and /media/* here17:46
freemangordonI am using uSD to store gigabytes of music17:46
freemangordonalso, camera is set to save on uSD17:46
freemangordonthis is not a niche usecase17:46
DocScrutinizer05yes, exactly - what about uSD. Do you think it's a smart thing to scan a 256GB of content for all media files each time you unplug USB from N900?17:47
DocScrutinizer05but that is exactly what tracker does17:47
freemangordoncool, and what is the solution? how you are sure nothing has changed and thumbnails are still valid after USB is disconnected?17:48
*** dmth|intevation1 has quit IRC17:49
DocScrutinizer05the solution is to build index (or call it cache or db or whatever) on read, not on insert or other triggers, and to store the data on uSD so it removes and inserts to the device together with the files this cache is built from17:49
DocScrutinizer05alternatively don't use cache at all17:49
freemangordonok, but how would that prevent re-scanning the whole FS after USB disconnect? you have no idea if the cache is still consistent17:50
DocScrutinizer05a .directory file in /myDocs/Music/ would automatically get invalidated even on a foreign devie when somebody writes a new file to that dir17:50
DocScrutinizer05just compare mtimes17:51
freemangordonand what would happen if I remove uSD and put it in another device/PC/laptop/whatever?17:51
DocScrutinizer05see above, I answered it in my last post17:51
DocScrutinizer05mtime of /. != mtime of /.directory -> .directory invalid17:52
freemangordonDocScrutinizer05: you mean to compare directory last modification time with the one stored in the cache? sounds sane, but those are implementation details17:53
freemangordonif tracker doesn;t do it like that....17:53
DocScrutinizer05no, this is a filesystem core property17:53
freemangordonah, I see17:53
DocScrutinizer05you don't store mtime of .directory inside .directory17:53
freemangordonbut that implies you have write access17:54
freemangordonyes, yes, got it17:54
DocScrutinizer05sory, afk, be back in a few hours17:54
*** arcean has quit IRC18:05
*** louisdk has joined #maemo18:11
*** dafox has joined #maemo18:48
*** flo_lap has joined #maemo18:53
*** strohalm has joined #maemo19:07
*** strohalm has joined #maemo19:07
*** strohalm has quit IRC19:20
*** Pali has joined #maemo19:31
Sicelothanks freemangordon - RE: tracker. i can't say i like it much either, but it can't be as bad as it can be made out to be. in any case, N900 was also meant for 'regular' users too, and tracker solves real problems (maybe not elegantly, but it gets the job done)19:32
*** dafox has quit IRC19:33
*** LauRoman has quit IRC20:02
*** LauRoman has joined #maemo20:02
*** M4rtinK has joined #maemo20:05
*** Kabouik has joined #maemo20:22
KotCzarnywhat the actual fuck?20:39
KotCzarnydummy file in EACH subdir?20:39
KotCzarnyi like the android idea of '.nomedia' file though, which helps making it's tracker to keep away from my ebooks tree for example20:40
*** TheKit has joined #maemo20:40
*** geaaru has quit IRC20:42
KotCzarnyso it only takes one file to make whole tree safe from thrashing the device20:42
Sicelotracker.cfg works more or less the same?20:43
KotCzarnysince you configure per-device20:43
KotCzarnyand .nomedia on my 32GB ebooks card can be safely moved between devices20:44
*** NeKit has quit IRC20:44
Sicelo>>racker solves real  problems (maybe not elegantly, but it gets the job done)20:45
KotCzarnyi've solved my problems with tracker by disabling it20:45
Siceloso .nomedia is more elegant :)20:45
Siceloi bet it's still running on your device20:46
KotCzarnysicelo: but it's only for android, though i assume it could be retrofitted to tracker too20:46
KotCzarnysicelo: probably, but it's denied scanning anything20:46
MaxdamantusMy trackerd is apparently just a shell script that does `exec true`21:01
DocScrutinizer05sad arguments21:21
DocScrutinizer05>>imagine DB in /var which is on NAND compared to uSD flash<< no, the tracker db is on /home which is eMMC. Do you know why /home is 2GB? this is the assumed max size of tracker db when using a 32GB uSD, so the gossip21:27
DocScrutinizer05so did I read sth like >>if we store all thumbnails there, soon there wouldn't be space left for pictures anymore<< or was that just a delusion? Guess what? when you run out of space on your storage for music/photos you are out of space and that's it. When you run out of space on /home though, you are in *serious* trouble21:29
DocScrutinizer05swapping your uSD for a fresh one can empty space (also for thumbnails) in your camera target dir. However swapping uSD will NOT free up space in /home automatically21:32
DocScrutinizer05au contraire when you got stuff on that new uSD already, odds are it will request even more space on top in /home/user21:33
DocScrutinizer05and NB we started at "have a dedicated user-defined directory for music (maybe 2 or 3 of them), and camera storage dir is hardcoded anyway. Now what's the big headache when we allow our tracker replacement to write a few hidden files to there? heck those dirs are *owned* by the apps using the tracker-replacement21:39
*** L29Ah has quit IRC21:40
DocScrutinizer05the directory structure is pretty much defined, at least for camera. For music I don't see anything or anybody but users themselfes using and making use of any directory structure in music dirs. Tracker is woefully agnostic of *any* directory structure incl all 'metainfo' from pathname. This is actually a BUG that makes handling impossible when you got similar files in multiple locations21:42
DocScrutinizer05and again, I'm primarily concerned about fixed storage and uSD that basically never gets removed. For a casual uSD of a friend's camera you insert, you could forbid creating 'cache' or thumbnails on the uSD and rather cache thumbnails in a shadow dir that gets nuked as soon as uSD gets umounted21:45
DocScrutinizer05loosely related: last time I checked, Gallery / mediaplayer told me for over 3 hours "Please wait! indexing..." after I changed content of eMMC and uSD and then immediately after boot tried to open those apps21:48
*** dafox has joined #maemo21:48
DocScrutinizer05I'd rather have a dirlist without any thumbnails to select what I want to liste to or watch, instead of such crap21:49
DocScrutinizer05thumbnails would get build in background whenever Fallery accessing a subdir/file21:50
DocScrutinizer05Gallery even21:50
*** LjL has quit IRC21:50
*** LjL has joined #maemo21:53
Sicelotracker and hildon-thumbnailerd are different entities, aren't they21:59
DocScrutinizer05as unrelated to each other as are systemd and journald22:07
*** sunshavi has quit IRC22:11
DocScrutinizer05IroN900:~# grep 'Feb *7.*tracker' /var/log/syslog|wc -l22:13
DocScrutinizer05 an absolutely normal reboot22:15
DocScrutinizer05so it's running for >1h just for verifying that nothing needs re-indexing22:20
*** sunshavi has joined #maemo22:29
*** flo_lap is now known as florian22:31
*** Cor-Ai has quit IRC22:37
*** L29Ah has joined #maemo22:41
*** Cor-Ai has joined #maemo22:42
*** strohalm has joined #maemo22:53
*** strohalm has joined #maemo22:53
*** strohalm has quit IRC22:56
*** strohalm has joined #maemo22:58
*** strohalm has joined #maemo22:58
*** strohalm has quit IRC23:04
*** jskarvad has quit IRC23:28
*** jonwil has joined #maemo23:30
*** louisdk has quit IRC23:39
*** florian has quit IRC23:48

Generated by 2.15.1 by Marius Gedminas - find it at!