| 00:00.57 | *** join/#maemo atk (Arch-TK@fsf/member/Arch-TK) |
| 00:17.51 | *** join/#maemo norayr (~noch@212.34.243.186) |
| 04:01.57 | *** join/#maemo lxp (~lxp@unaffiliated/lxp) |
| 04:16.10 | *** join/#maemo heroux (~heroux@gateway02.insomnia247.nl) |
| 05:09.29 | *** join/#maemo DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 05:14.17 | *** join/#maemo pagurus (~user@p4FDC3980.dip0.t-ipconnect.de) |
| 06:03.48 | *** join/#maemo arcean (~arcean@131.228.32.166) |
| 06:58.23 | *** join/#maemo dafox (~dafox@188.207.64.49) |
| 07:36.15 | *** join/#maemo jskarvad (~jskarvad@ip4-83-240-109-95.cust.nbox.cz) |
| 07:36.16 | *** join/#maemo jskarvad (~jskarvad@redhat/jskarvad) |
| 07:49.41 | KotCzarny | wth. o.O |
| 07:50.17 | KotCzarny | i've started oscp on terminal, switched virtual console, it steals usb keyboard somehow anyway |
| 07:50.47 | KotCzarny | but it might be something quirky with the keyboard itself as it's not working properly no matter if oscp is running or not |
| 07:53.16 | Vajb_ | well, one can never know what those closed blobs do. |
| 07:54.02 | KotCzarny | funny thing is it never acted that way, it's only when i connected this new kb |
| 07:54.46 | *** join/#maemo dmth|intevation (~dmth|inte@2001:470:747a:2a:6af7:28ff:fe64:1ded) |
| 07:56.03 | KotCzarny | kb itself registers twice |
| 07:56.08 | KotCzarny | o.O |
| 08:14.23 | *** join/#maemo esaym153 (~esaym153@75-1-182-8.lightspeed.snantx.sbcglobal.net) |
| 08:19.17 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 08:20.08 | *** join/#maemo florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 08:23.51 | KotCzarny | ahahah, so it finally happened |
| 08:23.56 | KotCzarny | Sorry, it seems that you are using an IP address or a proxy that is listed in the forum anti spam blacklist. |
| 08:28.46 | KotCzarny | solution in my case was just reconnecting the modem ;) |
| 08:29.03 | KotCzarny | bam! antispam subversed! ;0 |
| 08:58.50 | *** join/#maemo geaaru (~geaaru@host170-152-static.43-88-b.business.telecomitalia.it) |
| 09:16.47 | *** join/#maemo KotCzarny (ariel@31.135.195.151) |
| 09:40.02 | DocScrutinizer05 | tracker? DIE! |
| 09:41.47 | DocScrutinizer05 | ~tracker |
| 09:41.47 | 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?! https://wiki.gnome.org/Projects/Tracker/Documentation/Configuration |
| 09:44.01 | DocScrutinizer05 | also tracker concept is a fail in my book |
| 09:44.31 | DocScrutinizer05 | gnome mindset idiocy |
| 09:46.06 | DocScrutinizer05 | why the hell would we need a database that acts like a virtual filesystem? we got a *real* filesystem for that |
| 09:48.20 | DocScrutinizer05 | 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 |
| 09:52.07 | DocScrutinizer05 | tracjker is basically same bullshit like akonadi and I can't help but suspect they soon get merged and then assimilated by systemd |
| 09:54.37 | *** join/#maemo vectis3 (~user@88-145-16-172.host.pobb.as13285.net) |
| 09:58.52 | *** join/#maemo M4rtinK (~M4rtinK@ip-78-45-144-165.net.upcbroadband.cz) |
| 10:01.37 | DocScrutinizer05 | 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 |
| 10:01.39 | DocScrutinizer05 | 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 |
| 10:03.52 | *** join/#maemo N-Mi (~nicolas@adsl.n-mi.com) |
| 10:03.52 | *** join/#maemo N-Mi (~nicolas@calvix/staff/N-Mi) |
| 10:06.44 | *** join/#maemo sunshavi (~user@181.64.192.79) |
| 10:09.46 | KotCzarny | or just f*ck the media library and have some quick folders defined |
| 10:10.07 | KotCzarny | because really, gallery usually only needs camera folder |
| 10:10.15 | KotCzarny | and maybe user defined folder too |
| 10:10.53 | KotCzarny | and thumbnails could be generated on browse (assuming new files would be found) |
| 10:14.48 | *** join/#maemo ecloud (quassel@nat/qt/x-hzhntmcfhspvjqif) |
| 11:18.09 | DocScrutinizer05 | aka >>simply delivers a `ls -l $photodir` as result<< |
| 11:18.12 | DocScrutinizer05 | so yep |
| 11:18.55 | DocScrutinizer05 | prolly rather `ls -lR ...` |
| 11:21.01 | DocScrutinizer05 | 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...) |
| 11:22.33 | DocScrutinizer05 | with a shim you could simply pop up a requester asking user which category (or categories) they want to browse |
| 11:24.02 | DocScrutinizer05 | 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 |
| 11:25.05 | DocScrutinizer05 | mount namespaces to enable a unique session dbus interface |
| 11:25.49 | DocScrutinizer05 | rather unique dedicated session dbus, to be more precise |
| 11:27.51 | DocScrutinizer05 | 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 |
| 11:28.26 | DocScrutinizer05 | the tracker API is dbus |
| 11:28.29 | DocScrutinizer05 | so... |
| 11:30.27 | DocScrutinizer05 | *maybe* a LD_PRELOAD my-own-dbus.so Gallery could work too, instead of running a separate dbus instance in its own namespace |
| 11:33.18 | DocScrutinizer05 | 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 |
| 11:36.51 | DocScrutinizer05 | 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" |
| 11:38.51 | DocScrutinizer05 | 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 |
| 11:39.05 | DocScrutinizer05 | s/crating/creating/ |
| 11:56.57 | *** join/#maemo mp107 (~mp107@PC-109-125-232-42.wegrow.domtel.com.pl) |
| 12:20.08 | KotCzarny | tracker's cache shoulddnt live inside target dirs |
| 12:20.17 | KotCzarny | i would hate such trash autogeneratod |
| 12:22.05 | jon_y | thumbs.db everywhere |
| 12:29.37 | bencoh | :/ |
| 12:39.08 | *** join/#maemo juiceme (~juice@cerebro.liukuma.net) |
| 12:42.41 | *** join/#maemo Gadgetoid (~Gadgetoid@ip-78-109-177-202.ask4internet.com) |
| 12:48.15 | *** join/#maemo dmth|intevation1 (~dmth|inte@nat-guest.intevation.de) |
| 13:26.21 | *** join/#maemo florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 13:27.57 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 13:30.25 | *** join/#maemo M4rtinK (~M4rtinK@ip-78-45-144-165.net.upcbroadband.cz) |
| 13:33.49 | DocScrutinizer05 | 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 |
| 13:33.51 | DocScrutinizer05 | gets autogenerated and when by it |
| 14:14.14 | LjL | i understood some of them words Doc used |
| 14:22.35 | DocScrutinizer05 | LjL: can I help? |
| 14:23.06 | LjL | no it's fine, i was just bemusing on the fact i could barely understand what you said :) |
| 14:23.28 | DocScrutinizer05 | well, so maybe I can actually help |
| 14:25.07 | DocScrutinizer05 | 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 |
| 14:25.12 | LjL | 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! |
| 14:25.31 | DocScrutinizer05 | yes :-) |
| 14:26.03 | bencoh | DocScrutinizer05: the thing is a directory listing without cache would be a pain as well |
| 14:26.28 | LjL | for a short while it seemed we would all quickly be moving to database-inspired, "tagged" or whatever, filesystems |
| 14:26.41 | LjL | i think that whole part of hypothetical computing history has been erased from the books out of shame... |
| 14:26.47 | KotCzarny | n900 is from 2009 |
| 14:26.49 | DocScrutinizer05 | 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 |
| 14:26.55 | KotCzarny | developed from 2007-2008 |
| 14:27.01 | KotCzarny | so 10 year old tech |
| 14:27.01 | DocScrutinizer05 | bencoh: why? |
| 14:27.02 | KotCzarny | ;0 |
| 14:27.19 | bencoh | DocScrutinizer05: well, depends on how recursive you want to be and how many files you have there |
| 14:27.46 | DocScrutinizer05 | yeah, for ... sorry phonecall |
| 14:28.21 | KotCzarny | it should only cache thing that got browsed, dont overdo, cache is good, preemptive cache is overengineering on limited resources device |
| 14:41.19 | DocScrutinizer05 | 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 |
| 14:42.30 | DocScrutinizer05 | I think thumbnails should get stored in the directory where the pictures are, not in a database anywhere |
| 14:43.15 | DocScrutinizer05 | if only for sanity of usecase "uSD" |
| 14:46.41 | DocScrutinizer05 | 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 |
| 14:47.50 | DocScrutinizer05 | http://maemo.cloud-7.de/Gallery-N900-exploded/thumbs/ |
| 14:51.44 | DocScrutinizer05 | IroN900:~# time ls -lR /home/user/MyDocs/allofmp3/ |wc -l |
| 14:51.46 | DocScrutinizer05 | 1087 |
| 14:51.47 | DocScrutinizer05 | real 0m0.922s |
| 14:51.49 | DocScrutinizer05 | user 0m0.148s |
| 14:51.50 | DocScrutinizer05 | sys 0m0.391s |
| 14:52.26 | DocScrutinizer05 | I honestly don't think tracker is faster |
| 14:57.31 | enyc | hrrrrrrrrrrrm |
| 14:58.52 | enyc | 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'' ?? |
| 15:06.27 | *** join/#maemo L29Ah (~L29Ah@cl-154.led-01.ru.sixxs.net) |
| 15:08.38 | bencoh | I guess so |
| 15:11.11 | enyc | bencoh: whyso? |
| 15:12.20 | freemangordon | doubts |
| 15:13.28 | freemangordon | 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 |
| 15:13.49 | freemangordon | also, how would that work for remote FSs? |
| 15:15.28 | peetah | hello, happily coming back to n900 after 3 years, and I try to keep up to date with what could have changed |
| 15:15.35 | freemangordon | 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. |
| 15:15.41 | freemangordon | peetah: WB |
| 15:16.00 | peetah | freemangordon: thanks :) |
| 15:16.12 | peetah | as a starter, is there any XMPP client supporting OMEMO ? |
| 15:18.49 | bencoh | enyc: because I might be wrong, but I don't think other hard kernel dependencies were added to glibc |
| 15:23.16 | *** join/#maemo ecc3g (~eccerr0r@2602:46:3913:b400:5054:ff:fe37:7e04) |
| 15:32.47 | freemangordon | Wizzup: hi! any progress with devuan-maemo packages? |
| 15:35.39 | Wizzup | 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 |
| 15:35.59 | Wizzup | 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 |
| 15:36.16 | Wizzup | that's where the discussion stranded saturday or sunday I believe |
| 15:36.31 | parazyd | yep |
| 15:36.47 | parazyd | i'm releasing a new distro tomorrow so i'm caught up with that |
| 15:36.56 | parazyd | afterwards i'll start hacking on amprolla |
| 15:37.32 | freemangordon | ok, great |
| 15:37.44 | parazyd | Wizzup: fwiw, a separate amprolla instance will have to be running for maemo anyway |
| 15:37.57 | parazyd | and as far as i see it's not quite heavy software |
| 15:38.17 | DocScrutinizer05 | freemangordon: where else do you store thumbnails for remote filesystems? locally, forever? Not at all? |
| 15:38.25 | parazyd | for the beginning i'll just try to do the bare minimum so we get it as fast as we can |
| 15:38.33 | parazyd | (get it up and running) |
| 15:38.41 | freemangordon | parazyd: do we have the needed HW? |
| 15:39.06 | *** join/#maemo xy2_ (~xy2_@118.245.16.93.rev.sfr.net) |
| 15:39.09 | parazyd | i believe so |
| 15:39.15 | DocScrutinizer05 | also WHAT about >>having stuff stored in a DB placed where it should be is way better than doing ls every time<< |
| 15:39.26 | freemangordon | parazyd: ok |
| 15:39.29 | DocScrutinizer05 | this doesn't even make any sense |
| 15:40.07 | freemangordon | DocScrutinizer05: yes, it makes, imagine DB in /var which is on NAND compared to uSD flash |
| 15:40.25 | DocScrutinizer05 | 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? |
| 15:40.43 | freemangordon | afaik it doesn't work like that |
| 15:40.58 | freemangordon | it "monitors" the needed dirs |
| 15:41.08 | freemangordon | and receives signal on change |
| 15:41.14 | DocScrutinizer05 | it basically does, on top of an abomination made from scan-at-boot and inotify |
| 15:41.36 | freemangordon | yes, but this is one time only |
| 15:41.44 | DocScrutinizer05 | err aha |
| 15:42.03 | freemangordon | also, about remote dirs - no, there is no need to store the data forever |
| 15:42.47 | freemangordon | the point is - you can;t simply write some garbage (thumbnails) on a remote FS |
| 15:43.11 | DocScrutinizer05 | 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 |
| 15:43.22 | freemangordon | this feels so wrong that I can't even explain why :) |
| 15:43.58 | DocScrutinizer05 | no, tracker feels so wrong that no words can describe it |
| 15:44.28 | freemangordon | DocScrutinizer05: also, imagine every OS writes its own thumbnails - soon there will be no place for pictures ;) |
| 15:44.39 | DocScrutinizer05 | every OS??? |
| 15:44.51 | DocScrutinizer05 | dafaq how many OS you want to run on your N900? |
| 15:45.25 | freemangordon | DocScrutinizer05: what about uSD used to store music, videos and picures? |
| 15:46.00 | freemangordon | it might as well be put in an android phone, connected to my PC running Ubuntu,c connected to Windoze PC, etc |
| 15:46.04 | DocScrutinizer05 | also please never mind remote fs and other bizarre niche usecases, we are talking about N900 system and MyDocs and /media/* here |
| 15:46.30 | freemangordon | I am using uSD to store gigabytes of music |
| 15:46.51 | freemangordon | also, camera is set to save on uSD |
| 15:46.58 | freemangordon | this is not a niche usecase |
| 15:47.04 | DocScrutinizer05 | 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? |
| 15:47.14 | freemangordon | no |
| 15:47.28 | DocScrutinizer05 | but that is exactly what tracker does |
| 15:48.03 | freemangordon | cool, and what is the solution? how you are sure nothing has changed and thumbnails are still valid after USB is disconnected? |
| 15:49.21 | DocScrutinizer05 | 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 |
| 15:49.41 | DocScrutinizer05 | alternatively don't use cache at all |
| 15:50.20 | freemangordon | ok, but how would that prevent re-scanning the whole FS after USB disconnect? you have no idea if the cache is still consistent |
| 15:50.39 | DocScrutinizer05 | a .directory file in /myDocs/Music/ would automatically get invalidated even on a foreign devie when somebody writes a new file to that dir |
| 15:51.02 | DocScrutinizer05 | just compare mtimes |
| 15:51.21 | freemangordon | and what would happen if I remove uSD and put it in another device/PC/laptop/whatever? |
| 15:51.39 | DocScrutinizer05 | see above, I answered it in my last post |
| 15:52.47 | DocScrutinizer05 | mtime of /. != mtime of /.directory -> .directory invalid |
| 15:53.00 | freemangordon | DocScrutinizer05: you mean to compare directory last modification time with the one stored in the cache? sounds sane, but those are implementation details |
| 15:53.19 | freemangordon | if tracker doesn;t do it like that.... |
| 15:53.19 | DocScrutinizer05 | no, this is a filesystem core property |
| 15:53.42 | freemangordon | ah, I see |
| 15:53.57 | DocScrutinizer05 | you don't store mtime of .directory inside .directory |
| 15:54.08 | freemangordon | but that implies you have write access |
| 15:54.14 | freemangordon | yes, yes, got it |
| 15:54.27 | DocScrutinizer05 | sory, afk, be back in a few hours |
| 15:54.31 | freemangordon | ok |
| 16:11.25 | *** join/#maemo louisdk (~louisdk@5.103.130.65) |
| 16:48.16 | *** join/#maemo dafox (~dafox@188.207.67.246) |
| 16:53.17 | *** join/#maemo flo_lap (~fuchs@Maemo/community/contributor/florian) |
| 17:07.17 | *** join/#maemo strohalm (~smoofi@cpe-4c5e0c9246c5.ip-pool.rftonline.net) |
| 17:07.18 | *** join/#maemo strohalm (~smoofi@unaffiliated/strohi) |
| 17:31.18 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 17:32.22 | Sicelo | 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) |
| 18:02.59 | *** join/#maemo LauRoman (~LauRoman@5-14-178-85.residential.rdsnet.ro) |
| 18:05.47 | *** join/#maemo M4rtinK (~M4rtinK@ip-78-45-144-165.net.upcbroadband.cz) |
| 18:22.13 | *** join/#maemo Kabouik (~kabouik@32.232.202.84.customer.cdi.no) |
| 18:39.04 | KotCzarny | what the actual fuck? |
| 18:39.14 | KotCzarny | dummy file in EACH subdir? |
| 18:40.11 | KotCzarny | i like the android idea of '.nomedia' file though, which helps making it's tracker to keep away from my ebooks tree for example |
| 18:40.27 | *** join/#maemo TheKit (~nekit@178.45.157.55) |
| 18:42.38 | KotCzarny | so it only takes one file to make whole tree safe from thrashing the device |
| 18:43.31 | Sicelo | tracker.cfg works more or less the same? |
| 18:43.43 | KotCzarny | nope |
| 18:43.51 | KotCzarny | since you configure per-device |
| 18:44.06 | KotCzarny | and .nomedia on my 32GB ebooks card can be safely moved between devices |
| 18:45.33 | Sicelo | >>racker solves real problems (maybe not elegantly, but it gets the job done) |
| 18:45.50 | KotCzarny | i've solved my problems with tracker by disabling it |
| 18:45.51 | Sicelo | so .nomedia is more elegant :) |
| 18:46.20 | Sicelo | i bet it's still running on your device |
| 18:46.27 | KotCzarny | sicelo: but it's only for android, though i assume it could be retrofitted to tracker too |
| 18:46.41 | KotCzarny | sicelo: probably, but it's denied scanning anything |
| 19:01.01 | Maxdamantus | My trackerd is apparently just a shell script that does `exec true` |
| 19:21.04 | DocScrutinizer05 | sad arguments |
| 19:21.52 | APic | *shrug* |
| 19:27.26 | 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 gossip |
| 19:29.11 | DocScrutinizer05 | 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 |
| 19:32.14 | DocScrutinizer05 | 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 |
| 19:33.06 | DocScrutinizer05 | au contraire when you got stuff on that new uSD already, odds are it will request even more space on top in /home/user |
| 19:39.29 | DocScrutinizer05 | 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 |
| 19:42.48 | DocScrutinizer05 | 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 |
| 19:45.54 | DocScrutinizer05 | 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 |
| 19:48.09 | DocScrutinizer05 | 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 |
| 19:48.17 | *** join/#maemo dafox (~dafox@2a02:a448:c25a:1:7061:3b2a:37df:ded3) |
| 19:49.22 | DocScrutinizer05 | I'd rather have a dirlist without any thumbnails to select what I want to liste to or watch, instead of such crap |
| 19:50.03 | DocScrutinizer05 | thumbnails would get build in background whenever Fallery accessing a subdir/file |
| 19:50.16 | DocScrutinizer05 | Gallery even |
| 19:53.54 | *** join/#maemo LjL (~ljl@unaffiliated/ljl) |
| 19:59.14 | Sicelo | tracker and hildon-thumbnailerd are different entities, aren't they |
| 20:06.07 | DocScrutinizer05 | yes |
| 20:07.24 | DocScrutinizer05 | as unrelated to each other as are systemd and journald |
| 20:13.03 | DocScrutinizer05 | IroN900:~# grep 'Feb *7.*tracker' /var/log/syslog|wc -l |
| 20:13.04 | DocScrutinizer05 | 48065 |
| 20:15.26 | DocScrutinizer05 | http://paste.opensuse.org/29995858 an absolutely normal reboot |
| 20:20.59 | DocScrutinizer05 | so it's running for >1h just for verifying that nothing needs re-indexing |
| 20:29.09 | *** join/#maemo sunshavi (~user@181.64.192.79) |
| 20:41.24 | *** join/#maemo L29Ah (~L29Ah@cl-154.led-01.ru.sixxs.net) |
| 20:42.18 | *** join/#maemo Cor-Ai (~cor-ai@c-57d071d5.06-922-7570702.cust.bredbandsbolaget.se) |
| 20:53.51 | *** join/#maemo strohalm (~smoofi@cpe-4c5e0c9246c5.ip-pool.rftonline.net) |
| 20:53.51 | *** join/#maemo strohalm (~smoofi@unaffiliated/strohi) |
| 20:58.37 | *** join/#maemo strohalm (~smoofi@unaffiliated/strohi) |
| 21:30.56 | *** join/#maemo jonwil (~jonwil@27-33-80-219.tpgi.com.au) |
| 21:31.44 | jonwil | hi |
| 21:39.27 | Pali | hi! |
| 22:14.07 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 23:59.52 | *** join/#maemo kerio_ (kerio@bad.memes.vs.dank.ninja) |