[00:12:53] *** Quits: Horwitz (~mich1@p200300EC9BC58B00022268FFFE64E7C4.dip0.t-ipconnect.de) (Ping timeout: 250 seconds) [00:25:47] *** Joins: Horwitz (~mich1@p200300EC9BC13A00022268FFFE64E7C4.dip0.t-ipconnect.de) [00:25:48] *** ChanServ sets mode: +o Horwitz [05:24:19] KaZeR: couldn't validate that, but I think rethinkdb is only needed on master. So my approach is to not waste so much time on it. I have also seen that there was a fork of rethinkdb and some updates on the Docker images of rethinkdb so I personally don't put so much effort into this part. But the buildroot approach would be great. Yesterday I was working on our buildroot for raspberry Pi (and others) and converted [05:24:19] the current version to a proper BR2_EXTERNAL source. So we don't need to do silly copying when building. Also I think we can drop the device specific path? Because raspberry Pi is supported in upstream. [06:14:54] *** Joins: xenos1984 (~xenos1984@b1b8-e81d-f467-b5f7-d480-87c4-07d0-2001.dyn.estpak.ee) [06:14:54] *** ChanServ sets mode: +v xenos1984 [15:26:18] *** Joins: mineque28 (252f4697@public-gprs368470.centertel.pl) [15:26:18] *** ChanServ sets mode: +v mineque28 [15:26:44] *** Quits: Mineque (~mineque@62-210-136-72.rev.poneytelecom.eu) (Disconnected by services) [15:26:53] *** mineque28 is now known as mineque [15:27:11] hi [17:24:50] kazer: you are right about the build times [17:24:58] can you tell me more about the buildroot approach? [17:29:12] jkoan: i think that there's value to be able to run the farm without connection to a master node, just in case there's an issue with the master node [17:29:46] ilovekiruna: using buildroot we can generate a ready to use image that's about 200MB. you just flash that onto your sdcard and you're ready to go [17:30:06] downside is that there is no package manager. so you can't easily add packages if needed to an already running system [17:30:51] upsides are that once we have an image it's piece of cake to install, and since these images are immutable it's easy to test upgrades and revert if something goes wrong [17:31:25] jkoan: the device specific paths are still needed because the rpi3 needs a few tweaks compared to the rpi2 [17:31:36] i guess that you were talking about the navit-buildroot repository? [17:37:43] @KaZeR but even rpi3 is in mainline [17:43:23] jkoan: correct, but it's about the defconfig file you need to use when building. Last time I checked, a rpi3 image wouldn't boot on a rpi2 [17:43:24] *** Joins: gernot2 (bc63751d@dslb-188-099-117-029.188.099.pools.vodafone-ip.de) [17:43:29] hi [17:43:34] hi gernot2 [17:44:49] kazer: tomtom One GPS is working. Not good, but usable. [17:46:44] In Navit tomtom-minimal is the path to locales wrong [17:48:39] Also i thonk about a swapfile instead a swappartition for 32M Devices [17:50:12] at long term, it shred the Flash, but make the device better usable. [18:00:20] ok good to know. which image did you use? navitom-minimal? [18:02:19] the image you wrote to me some days ago. [18:02:26] yes [18:16:47] ok thanks. fixing the locales path shouldn't be hard I think [18:16:59] when you say not good but usable, is this releated to the swapfile? [18:18:26] No, its a GPS-problem. Possible depends the week rollover. [18:19:03] my device detects only 3 to 4 satelites [18:19:44] May also be its broken by time. [18:20:51] The Swap solves the problem that navit crash e.g. if you search a street in munich. [18:21:21] This takes more then the 32M memory [18:21:35] oh i see [18:22:39] what i've done on a previous device is to enforce a date. it's ugly but it helped fix some gps issues : https://github.com/pgrandin/navit-buildroot/blob/master/speedsaver/overlay/etc/init.d/S50gpsd#L13 [18:22:55] kazer: do i understand it correctly that I first build my image with build.sh and then repackage it via buildroot? [18:25:25] yes, TT date is today Thu Feb 3 00:55:57 UTC 2000 [18:29:44] gernot2: it's worth trying to update that and restart the gps daemon [18:30:25] ilovekiruna: not exactly. buildroot itself will build the packages and the image. there's 2 build.sh script in my repo : one to prepare the actual build, and one to reduce the verbosity [18:30:35] i can show you how to build a test image if you want [18:30:36] My tt dont use gpsd. It pipes the data via gltt [18:31:21] after some cleanups i can send the opentom binary to git [18:33:01] Iḿ not sure that it is possible to build on a actual system. [18:33:33] kazer doesnt that require cross-compiling? [18:45:09] ilovekiruna: it does, but buildroot takes care of that for you [18:45:33] gernot2: what do you mean build on a actual system? you mean build navitom locally? [18:47:00] no. Build full opentom environment on a actual linux system. I know navitom is to build. [18:50:44] ha! well i think that we could backport some of the fixes we made [19:05:25] now my opento, is 34M zip [19:06:47] kazer: why backpost instead of update? [19:06:55] need more fixes :-) [19:32:19] if issue 802 (android build) is solved i try to build navitom in my environment. [19:35:32] jkoan: also because we never tested building more, as our focus was getting navit to run on this [19:38:19] @KaZeR working on buildroot for navit 😃 [19:38:20] https://cdn.discordapp.com/attachments/500190750085087235/605484269833420840/unknown.png [19:50:00] jkoan: are you building your own navit package? [19:51:26] i used https://github.com/navit-gps/buildroot as a stardingpoint to update it. My goal is to support every devices supported by buildroot, and hopefully in some time add tomtom support to buildroot [19:51:45] ont important step is to make the L [19:52:06] tomtom support will be tough because it requires a very old kernel, but it's worth a shot [19:53:00] looks like i have some updates in my own repo. i'll push them to the navit-gps repo in order to avoid duplicated work [19:53:05] one importent step is to make the buildroot Package capable of BR2_EXTERNAL (https://buildroot.org/downloads/manual/manual.html#outside-br-custom) [19:53:17] (Y) [19:54:59] the problem with tomtom is that you need a complete base system. [19:55:16] you cant use the original [19:55:16] yes, i know [19:55:32] yes, that is not the problem with buildroot [19:55:44] Ok [19:56:09] this is exactly what buildroot does. The only Problem is the really old linux kernel for tomtom [19:58:57] yes, this and the many different TT-Devices and the binary copyrighted gltt GPS-driver for some devices [19:59:14] and that kernel is required for the barcelona chips drivers [20:00:12] yes, gltt will still be a problem (at least until we break the data format) [20:01:54] it's not so much gltt, but more the driver that exposes the serial port that gltt uses to transform the binary stream [20:04:38] yes, that also 😄 but we can make that work 😄 [20:05:19] yeah sure we can backport the kernel patch to a more recent kernel :) easy peasy [20:06:02] i think that there are better things to invest time (include sleeping) [20:06:56] gltt comes most with 32M devices. And this is a big problem [20:19:35] by [20:20:33] *** Quits: gernot2 (bc63751d@dslb-188-099-117-029.188.099.pools.vodafone-ip.de) (Quit: gernot2) [22:45:03] *** Quits: mineque (252f4697@public-gprs368470.centertel.pl) (Ping timeout: 260 seconds) [22:45:52] *** Joins: Mineque (~mineque@62-210-136-72.rev.poneytelecom.eu) [22:45:52] *** ChanServ sets mode: +v Mineque [23:08:06] *** Quits: xenos1984 (~xenos1984@b1b8-e81d-f467-b5f7-d480-87c4-07d0-2001.dyn.estpak.ee) (Quit: Leaving.)