**** BEGIN LOGGING AT Mon Feb 27 03:00:01 2017 Feb 27 07:49:41 wth. o.O Feb 27 07:50:17 i've started oscp on terminal, switched virtual console, it steals usb keyboard somehow anyway Feb 27 07:50:47 but it might be something quirky with the keyboard itself as it's not working properly no matter if oscp is running or not Feb 27 07:53:16 well, one can never know what those closed blobs do. Feb 27 07:54:02 funny thing is it never acted that way, it's only when i connected this new kb Feb 27 07:56:03 kb itself registers twice Feb 27 07:56:08 o.O Feb 27 08:23:51 ahahah, so it finally happened Feb 27 08:23:56 Sorry, it seems that you are using an IP address or a proxy that is listed in the forum anti spam blacklist. Feb 27 08:28:46 solution in my case was just reconnecting the modem ;) Feb 27 08:29:03 bam! antispam subversed! ;0 Feb 27 09:40:02 tracker? DIE! Feb 27 09:41:47 ~tracker Feb 27 09:41:47 ""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?! https://wiki.gnome.org/Projects/Tracker/Documentation/Configuration Feb 27 09:44:01 also tracker concept is a fail in my book Feb 27 09:44:31 gnome mindset idiocy Feb 27 09:46:06 why the hell would we need a database that acts like a virtual filesystem? we got a *real* filesystem for that Feb 27 09:48:20 OOH 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 explode Feb 27 09:52:07 tracjker is basically same bullshit like akonadi and I can't help but suspect they soon get merged and then assimilated by systemd Feb 27 10:01:37 I *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 it Feb 27 10:01:39 doesn'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 query Feb 27 10:09:46 or just f*ck the media library and have some quick folders defined Feb 27 10:10:07 because really, gallery usually only needs camera folder Feb 27 10:10:15 and maybe user defined folder too Feb 27 10:10:53 and thumbnails could be generated on browse (assuming new files would be found) Feb 27 11:18:09 aka >>simply delivers a `ls -l $photodir` as result<< Feb 27 11:18:12 so yep Feb 27 11:18:55 prolly rather `ls -lR ...` Feb 27 11:21:01 I 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...) Feb 27 11:22:33 with a shim you could simply pop up a requester asking user which category (or categories) they want to browse Feb 27 11:24:02 I think with mount(8) namespaces and dbus trickery this shouldn't be too hard to implement without patches to any system infra or any apps Feb 27 11:25:05 mount namespaces to enable a unique session dbus interface Feb 27 11:25:49 rather unique dedicated session dbus, to be more precise Feb 27 11:27:51 dbus 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 is Feb 27 11:28:26 the tracker API is dbus Feb 27 11:28:28 so... Feb 27 11:30:27 *maybe* a LD_PRELOAD my-own-dbus.so Gallery could work too, instead of running a separate dbus instance in its own namespace Feb 27 11:33:18 note 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 does Feb 27 11:36:51 theoretically 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" Feb 27 11:38:51 I 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 stuff Feb 27 11:39:05 s/crating/creating/ Feb 27 11:39:06 DocScrutinizer05 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 stuff Feb 27 12:20:08 tracker's cache shoulddnt live inside target dirs Feb 27 12:20:17 i would hate such trash autogeneratod Feb 27 12:22:05 thumbs.db everywhere Feb 27 12:29:37 :/ Feb 27 13:33:49 I 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 what Feb 27 13:33:51 gets autogenerated and when by it Feb 27 14:14:15 i understood some of them words Doc used Feb 27 14:22:35 LjL: can I help? Feb 27 14:23:07 no it's fine, i was just bemusing on the fact i could barely understand what you said :) Feb 27 14:23:28 well, so maybe I can actually help Feb 27 14:25:07 tracker 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 info Feb 27 14:25:12 all 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! Feb 27 14:25:31 yes :-) Feb 27 14:26:03 DocScrutinizer05: the thing is a directory listing without cache would be a pain as well Feb 27 14:26:28 for a short while it seemed we would all quickly be moving to database-inspired, "tagged" or whatever, filesystems Feb 27 14:26:41 i think that whole part of hypothetical computing history has been erased from the books out of shame... Feb 27 14:26:47 n900 is from 2009 Feb 27 14:26:49 and 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 bloat Feb 27 14:26:55 developed from 2007-2008 Feb 27 14:27:01 so 10 year old tech Feb 27 14:27:01 bencoh: why? Feb 27 14:27:02 ;0 Feb 27 14:27:19 DocScrutinizer05: well, depends on how recursive you want to be and how many files you have there Feb 27 14:27:46 yeah, for ... sorry phonecall Feb 27 14:28:21 it should only cache thing that got browsed, dont overdo, cache is good, preemptive cache is overengineering on limited resources device Feb 27 14:41:19 yeah, 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 thumbnails Feb 27 14:42:30 I think thumbnails should get stored in the directory where the pictures are, not in a database anywhere Feb 27 14:43:15 if only for sanity of usecase "uSD" Feb 27 14:46:41 see (random example) http://maemo.cloud-7.de/Gallery-N900-exploded/ 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 completely Feb 27 14:47:50 http://maemo.cloud-7.de/Gallery-N900-exploded/thumbs/ Feb 27 14:51:44 IroN900:~# time ls -lR /home/user/MyDocs/allofmp3/ |wc -l Feb 27 14:51:46 1087 Feb 27 14:51:47 real 0m0.922s Feb 27 14:51:49 user 0m0.148s Feb 27 14:51:50 sys 0m0.391s Feb 27 14:52:26 I honestly don't think tracker is faster Feb 27 14:57:31 hrrrrrrrrrrrm Feb 27 14:58:52 Wondering: will Stretch libc6 (and everything else!!!) likely be persuadable to work on 2.6.28 kernel as was the case with jessie chroot ''backporting'' ?? Feb 27 15:08:39 I guess so Feb 27 15:11:11 bencoh: whyso? Feb 27 15:12:20 * freemangordon doubts Feb 27 15:13:28 DocScrutinizer05: 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, etc Feb 27 15:13:49 also, how would that work for remote FSs? Feb 27 15:15:28 hello, happily coming back to n900 after 3 years, and I try to keep up to date with what could have changed Feb 27 15:15:36 not 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. Feb 27 15:15:41 peetah: WB Feb 27 15:16:00 freemangordon: thanks :) Feb 27 15:16:12 as a starter, is there any XMPP client supporting OMEMO ? Feb 27 15:18:49 enyc: because I might be wrong, but I don't think other hard kernel dependencies were added to glibc Feb 27 15:32:47 Wizzup: hi! any progress with devuan-maemo packages? Feb 27 15:35:39 yes 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 autobuilds Feb 27 15:35:59 I 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 SOMEWHERE Feb 27 15:36:16 that's where the discussion stranded saturday or sunday I believe Feb 27 15:36:31 yep Feb 27 15:36:47 i'm releasing a new distro tomorrow so i'm caught up with that Feb 27 15:36:56 afterwards i'll start hacking on amprolla Feb 27 15:37:32 ok, great Feb 27 15:37:44 Wizzup: fwiw, a separate amprolla instance will have to be running for maemo anyway Feb 27 15:37:57 and as far as i see it's not quite heavy software Feb 27 15:38:17 freemangordon: where else do you store thumbnails for remote filesystems? locally, forever? Not at all? Feb 27 15:38:25 for the beginning i'll just try to do the bare minimum so we get it as fast as we can Feb 27 15:38:33 (get it up and running) Feb 27 15:38:41 parazyd: do we have the needed HW? Feb 27 15:39:09 i believe so Feb 27 15:39:15 also WHAT about >>having stuff stored in a DB placed where it should be is way better than doing ls every time<< Feb 27 15:39:26 parazyd: ok Feb 27 15:39:30 this doesn't even make any sense Feb 27 15:40:07 DocScrutinizer05: yes, it makes, imagine DB in /var which is on NAND compared to uSD flash Feb 27 15:40:25 you're aware that tracker as well needs to "do ls every time" since it can't know if local db is up to date? Feb 27 15:40:43 afaik it doesn't work like that Feb 27 15:40:58 it "monitors" the needed dirs Feb 27 15:41:08 and receives signal on change Feb 27 15:41:13 it basically does, on top of an abomination made from scan-at-boot and inotify Feb 27 15:41:36 yes, but this is one time only Feb 27 15:41:44 err aha Feb 27 15:42:03 also, about remote dirs - no, there is no need to store the data forever Feb 27 15:42:47 the point is - you can;t simply write some garbage (thumbnails) on a remote FS Feb 27 15:43:11 honestly 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 away Feb 27 15:43:22 this feels so wrong that I can't even explain why :) Feb 27 15:43:58 no, tracker feels so wrong that no words can describe it Feb 27 15:44:28 DocScrutinizer05: also, imagine every OS writes its own thumbnails - soon there will be no place for pictures ;) Feb 27 15:44:39 every OS??? Feb 27 15:44:51 dafaq how many OS you want to run on your N900? Feb 27 15:45:25 DocScrutinizer05: what about uSD used to store music, videos and picures? Feb 27 15:46:00 it might as well be put in an android phone, connected to my PC running Ubuntu,c connected to Windoze PC, etc Feb 27 15:46:04 also please never mind remote fs and other bizarre niche usecases, we are talking about N900 system and MyDocs and /media/* here Feb 27 15:46:30 I am using uSD to store gigabytes of music Feb 27 15:46:51 also, camera is set to save on uSD Feb 27 15:46:58 this is not a niche usecase Feb 27 15:47:04 yes, 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? Feb 27 15:47:14 no Feb 27 15:47:28 but that is exactly what tracker does Feb 27 15:48:03 cool, and what is the solution? how you are sure nothing has changed and thumbnails are still valid after USB is disconnected? Feb 27 15:49:21 the 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 from Feb 27 15:49:41 alternatively don't use cache at all Feb 27 15:50:20 ok, but how would that prevent re-scanning the whole FS after USB disconnect? you have no idea if the cache is still consistent Feb 27 15:50:39 a .directory file in /myDocs/Music/ would automatically get invalidated even on a foreign devie when somebody writes a new file to that dir Feb 27 15:51:02 just compare mtimes Feb 27 15:51:21 and what would happen if I remove uSD and put it in another device/PC/laptop/whatever? Feb 27 15:51:39 see above, I answered it in my last post Feb 27 15:52:47 mtime of /. != mtime of /.directory -> .directory invalid Feb 27 15:53:00 DocScrutinizer05: you mean to compare directory last modification time with the one stored in the cache? sounds sane, but those are implementation details Feb 27 15:53:19 if tracker doesn;t do it like that.... Feb 27 15:53:19 no, this is a filesystem core property Feb 27 15:53:42 ah, I see Feb 27 15:53:57 you don't store mtime of .directory inside .directory Feb 27 15:54:08 but that implies you have write access Feb 27 15:54:14 yes, yes, got it Feb 27 15:54:27 sory, afk, be back in a few hours Feb 27 15:54:31 ok Feb 27 17:32:18 thanks 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) Feb 27 18:39:04 what the actual fuck? Feb 27 18:39:14 dummy file in EACH subdir? Feb 27 18:40:11 i like the android idea of '.nomedia' file though, which helps making it's tracker to keep away from my ebooks tree for example Feb 27 18:42:38 so it only takes one file to make whole tree safe from thrashing the device Feb 27 18:43:31 tracker.cfg works more or less the same? Feb 27 18:43:43 nope Feb 27 18:43:51 since you configure per-device Feb 27 18:44:06 and .nomedia on my 32GB ebooks card can be safely moved between devices Feb 27 18:45:33 >>racker solves real problems (maybe not elegantly, but it gets the job done) Feb 27 18:45:50 i've solved my problems with tracker by disabling it Feb 27 18:45:51 so .nomedia is more elegant :) Feb 27 18:46:20 i bet it's still running on your device Feb 27 18:46:27 sicelo: but it's only for android, though i assume it could be retrofitted to tracker too Feb 27 18:46:41 sicelo: probably, but it's denied scanning anything Feb 27 19:01:01 My trackerd is apparently just a shell script that does `exec true` Feb 27 19:21:04 sad arguments Feb 27 19:21:52 *shrug* Feb 27 19:27:26 >>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 gossip Feb 27 19:29:11 so 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* trouble Feb 27 19:32:12 swapping 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 automatically Feb 27 19:33:06 au contraire when you got stuff on that new uSD already, odds are it will request even more space on top in /home/user Feb 27 19:39:29 and 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-replacement Feb 27 19:42:48 the 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 locations Feb 27 19:45:54 and 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 umounted Feb 27 19:48:09 loosely 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 apps Feb 27 19:49:22 I'd rather have a dirlist without any thumbnails to select what I want to liste to or watch, instead of such crap Feb 27 19:50:03 thumbnails would get build in background whenever Fallery accessing a subdir/file Feb 27 19:50:16 Gallery even Feb 27 19:59:14 tracker and hildon-thumbnailerd are different entities, aren't they Feb 27 20:06:08 yes Feb 27 20:07:24 as unrelated to each other as are systemd and journald Feb 27 20:13:03 IroN900:~# grep 'Feb *7.*tracker' /var/log/syslog|wc -l Feb 27 20:13:04 48065 Feb 27 20:15:26 http://paste.opensuse.org/29995858 an absolutely normal reboot Feb 27 20:20:59 so it's running for >1h just for verifying that nothing needs re-indexing Feb 27 21:31:44 hi Feb 27 21:39:27 hi! Feb 28 00:00:13 Finally getting somewhere with this transport app :) Feb 28 00:10:09 Now I just need to spend some time reading the networking chapter of my QT4 book :) **** ENDING LOGGING AT Tue Feb 28 03:00:00 2017