--- Log opened Tue Sep 04 00:00:38 2018
03:01 #navit: <+jkoan> genesis: aerostitch is our debian maintainer and Kazer another team member does know him in person. And all those thickets are from sourceforge because we cleaned up those and made them vee them to github
03:03 #navit: <+jkoan> And partially you are right, the development is sometimes quite slow, but we are working to clean up everything and make it good to work with it again, prong it up to date and so on.
03:04 #navit: < genesis> yeap not easy to enter in all this stuff that are not totally closed
03:04 #navit: < genesis> sf, trac etc
03:04 #navit: < genesis> some reference to the svn (in 2018)
03:05 #navit: < genesis> btw for today i think we have some great progress in the cleanup
03:06 #navit: <+jkoan> And the reason for the circleci Docker image is that we are building on circleci, so we use there image. Also they do the update the images frequently which is really what we need
03:07 #navit: < genesis> i really think we could have only one image with all the stuff, what do you think ?
03:08 #navit: <+jkoan> Don't know because of the outdated wince toolchain
03:09 #navit: < genesis> not in one day :)
03:12 #navit: < genesis> imagine with a small documentation, people could use only one image to test their modification in one action.
03:12 #navit: <+jkoan> BTW, also the project you shared is not available anymore. The git servers for the submodules are down. And this was where all sources came from, so we need zu reinvest into this to build and maintain a toolchain. And this is on one side good and on the other side bad because we can make a up to date toolchain but we don't have the Man power to maintain it
03:14 #navit: < genesis> oki
03:18 #navit: < genesis> the guy is active, we could ask him to fix submodule in github
03:18 #navit: < genesis> not too much work, and running such old tools is not really a pb
03:20 #navit: < genesis> and wince could stay like it is, i'm not make upgrade this a priority, we have to upgrade cmakefiles 2.6 to 3.2, enough work 
03:21 #navit: < genesis> btw, lot of his repository are about CE toolchain ;)
03:22 #navit: < genesis> i'm pretty sure it would fix that quickly, who make a PR ?
03:22 #navit: < genesis> s/PR/issue
03:23 #navit: < genesis> the guy is german, i think he won't let useless non fixed code so long :)
03:29 #navit: < genesis> git://git.xcsoar.org/xcsoar/max/cegcc-gcc.git => https://github.com/davidwed/cegcc-gcc
03:35 #navit: <+jkoan> I am also Germany, just for your interest
03:35 #navit: < genesis> fine fine :-)
03:36 #navit: < genesis> don't break my stereotype on german :D
03:50 #navit: < genesis> jkoan : max is cirrus on #xcsoar, we should invite him here and discuss 
03:52 #navit: < genesis> i did
04:23 #navit: < genesis> https://github.com/XCSoar/XCSoar/commit/bc029282720149d5dc1fd588c03866b20efda832 MaxKellermann drop wince support himself on xcsoar
04:24 #navit: < genesis> 3 years ago.
04:32 #navit: < genesis> https://github.com/XCSoar/XCSoar/commit/30e53203593bed9e002638c57f4ad86d13b4daa9 is the documentation about install http://max.kellermann.name/download/xcsoar/devel/cegcc/
04:42 -!- xenos1984 [~xenos1984@2001:bb8:2002:200:6651:6ff:fe53:a120] has joined #navit
04:42 -!- mode/#navit [+v xenos1984] by ChanServ
06:00 -!- naggety [~naggety@141.red-2-141-15.dynamicip.rima-tde.net] has joined #navit
06:43 -!- ilovekiruna [~ilovekiru@ip1f12af77.dynamic.kabel-deutschland.de] has quit [Ping timeout: 245 seconds]
10:13 #navit: < genesis> jkoan fixed submodule ;)
10:30 #navit: <+jkoan> On my cegcc fork? More or less, two are missing currently
10:47 #navit: < genesis> on the max one
10:48 #navit: < genesis> only one missing there ;)
10:48 #navit: < genesis> and i think we don't need it.
10:48 #navit: < genesis> btw he pushed change he mades for a company
13:46 #navit: < genesis> jkoan https://github.com/navit-gps/navit/pull/655 can you merge please ?
13:46 #navit: < genesis> ho
13:46 #navit: < genesis> the fastest i see in my life :D
13:48 #navit: <+jkoan> And I even didn't have read your message here on irc
13:49 #navit: < genesis> :-) thanks
14:02 -!- naggety [~naggety@141.red-2-141-15.dynamicip.rima-tde.net] has quit [Quit: Konversation terminated!]
14:47 -!- xenos1984 [~xenos1984@2001:bb8:2002:200:6651:6ff:fe53:a120] has quit [Quit: Leaving.]
15:19 #navit: < genesis> not so fast for 656 jkoan :]
15:46 -!- xenos1984 [~xenos1984@22-164-191-90.dyn.estpak.ee] has joined #navit
15:46 -!- mode/#navit [+v xenos1984] by ChanServ
16:20 #navit: <@KaZeR> hi there
16:22 #navit: <+jkoan> hi KaZeR
16:42 #navit: <@KaZeR> genesis | this is unsane source and a ci process complain about a whitespace when you try to remove thousand of compiler warning and useless files           
16:42 #navit: <@KaZeR> i am just having a quick glance at the backlog. genesis are you frustrated by our CI?
16:43 #navit: <@KaZeR> +jkoan | the tomtom build is finished, btw it took ~23mins and this is the time we dont have when we want to test if navit is compiling         
16:43 #navit: <@KaZeR> we can put all of the toolchain builds in a docker image and only build navit from the ci using that image. it should stay within minutes
16:47 #navit: <+jkoan> i know, i said the same thing yesterday
16:48 #navit: <+jkoan> but where do you see those 23mins?
16:48 #navit: <@KaZeR> you said that it was taking 23 min :)
16:49 #navit: <+jkoan> to build the docker image itself
16:49 #navit: <@KaZeR> i was mostly glancing at the backlog, way too much to catch up since last week :)
16:49 #navit: <@KaZeR> ha, yeah for the docker image it's ok
16:49 #navit: <@KaZeR> we don't need to do that that often
16:51 #navit: <+jkoan> yes, but also the tomtom-ng image is now automated ;)
16:52 #navit: <+jkoan> tomtom build on trunk is <2min
16:55 #navit: <+jkoan> the build will also update when the ubuntu base image is updated
16:56 #navit: < genesis> KaZeR : yeah not very pleased to hack in cmakefiles, and don't want to change too much in target i can't really live test
16:57 #navit: <@KaZeR> genesis: how can we make this easier for you?
16:59 #navit: < genesis> help me fixing android and win32 :)
17:00 #navit: < genesis> i don't use this stuff and i'm more about ignoring them that spend on it , i did already done too muche :)
17:02 #navit: <@KaZeR> fair enough :) what's broken on android? (as i mentioned i only glanced at the logs)
17:02 #navit: <@KaZeR> jkoan: do you know how to update the translations from launchpad ?
17:03 #navit: <+jkoan> not now, but i want to lern :D i just wanted to say that we need to automate the update ;)
17:04 #navit: <@KaZeR> we need to, but launchpad doesn't provide an api which make it not so easy
17:06 #navit: <+jkoan> launchpad does not have a hook or something like that?
17:07 #navit: <@KaZeR> not really. at least not the last time i looked into it. 
17:08 #navit: <+jkoan> there seems to be a python lib
17:09 #navit: <+jkoan> https://help.launchpad.net/API
17:10 #navit: <@KaZeR> jkoan: https://github.com/navit-gps/navit/pull/658 
17:11 #navit: <+jkoan> ah okay ^^ 
17:12 #navit: <@KaZeR> api : API (last edited 2011-05-26 06:40:05 by mbp) 
17:12 #navit: <+jkoan> i meant the http api ;)
17:12 #navit: <@KaZeR> i don't believe that the translation part has ever been exposed via the API, but it's worth double checking
17:13 #navit: <@KaZeR> part of the problem is that the export of the .po files is asynchronous. you request a po, and launchpad queues the generation and sends you an email when it's ready
17:13 #navit: <@KaZeR> it used to be 15 minutes, now it's usually less than 1min. but still asynchronous
17:14 #navit: <+jkoan> CodeFactor does not like some things of your PR ;) 
17:14 #navit: <@KaZeR> genesis: is that you? https://github.com/navit-gps/navit/pull/652/commits 
17:14 #navit: <@KaZeR> jkoan: 10 issues! oh shit
17:15 #navit: <@KaZeR> ha easy to fix
17:15 #navit: <+jkoan> jep
17:15 #navit: < genesis> yes KaZeR ; try to redo things to where i was and update comment to say how people can help
17:16 #navit: < genesis> i've quite fix android and win32 but i fed up, i've some gfx glitches and navigation issue to fix 
17:16 #navit: <@KaZeR> genesis: ok cool. And bonjour :D
17:17 #navit: < genesis> bonsoir
17:17 #navit: < genesis> guten tag jkoan , ich sprache Deuscht jünger
17:17 #navit: < genesis> but it was 15 years old :')
17:18 #navit: < genesis> basic idea, make your target able to compile on cmake > 3.2
17:18 #navit: < genesis> long term, try to unify in one devel-docker image based on latest LTS.
17:19 #navit: < genesis> then i could fix things like #650 the right way.
17:25 #navit: <+jkoan> kazer could you add me on launchpad?
17:25 #navit: <@KaZeR> sure. what's your account?
17:25 #navit: <+jkoan> https://launchpad.net/~jkoan
17:27 #navit: <@KaZeR> done
17:27 #navit: <@KaZeR> you're an admin there now, although it shouldn't be required to manage the translations
17:37 #navit: <+jkoan> KaZeR: why do we have set the Navit code source to Bazaar instead of git? :D
17:38 #navit: <@KaZeR> iirc it's because launchpad kind of requires it. But maybe it has changed now, this was setup YEARS ago :)
17:38 #navit: <@KaZeR> feel free to poke around and see if we can update that
17:38 #navit: <+jkoan> okay
17:38 #navit: <+jkoan> thx
17:51 #navit: <+jkoan> KaZeR: dont know how to setup it but: "Launchpad can commit daily snapshots of the translations for this 	  release series to a code branch."  i will try to set it up :)
17:52 #navit: <@KaZeR> genesis: so your win32 build currently fails because of error: static declaration of 'mempcpy' follows non-static declaration 
17:52 #navit: <@KaZeR> which seems to be caused by the fact that it builds using the version in '/support' instead of a system-provided one
17:53 #navit: <@KaZeR> jkoan: interesting. I think that it will only commit against a launchpad-hosted repository though. but definitely worth a shot
17:53 #navit: <+jkoan> but also easier then the email thing
17:58 -!- tryagain [~quassel@217.107.194.19] has joined #navit
17:58 -!- mode/#navit [+o tryagain] by ChanServ
17:59 #navit: <@KaZeR> jkoan: probably indeed
17:59 #navit: <@KaZeR> more scriptable too
17:59 #navit: <+jkoan> jep
18:02 #navit: <@KaZeR> genesis: here's a fix for your win32 issue : update gettext to 0.19 in navit/support/gettext_intl
18:03 #navit: <@KaZeR> basically just delete the existing folder, replace it with the new one and copy libgnuintl.h from the old one to the new one
18:03 #navit: <@KaZeR> this seems to work.. until we hit the next issue :)
18:03 #navit: <@KaZeR> genesis: from http://ftp.gnu.org/pub/gnu/gettext/gettext-0.19.8.1.tar.xz 
18:04 #navit: <@KaZeR> i can't push a fix to your branch as it's in your own repo
18:17 #navit: <@tryagain> genesis you seem to have been asking about who's still use WinCE. There are lots of such new devices stil made and saled.  For example, see https://translate.google.ru/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=https%3A%2F%2Fwww.dns-shop.ru%2Fcatalog%2Frecipe%2F599b526831b6834d%2Fnavigatory-windows%2F%3Ffinalize%3D1&edit-text=&act=url
18:21 #navit: <@KaZeR> hey tryagain :)
18:21 #navit: <@tryagain> hey KaZeR and all
18:24 #navit: < genesis> yes tryagain i'm just a foss guy who don't really care.
18:25 #navit: < genesis> and KaZeR i'd prefer to update to latest LTS and fix it in my PR, and we shouldn't have support directory imho
18:26 #navit: < genesis> target maintainer can script the compilation of 3rd party
18:27 #navit: < genesis> that's not navit business, keep it clean. what a mess to find-grep with such overloaded thing
18:28 #navit: <@KaZeR> well iirc the intent of the support directory is to provide a sane and tested support for platforms where our dependencies are not provided as an easy to install package
18:28 #navit: <@KaZeR> wince/win32 is actually a good example. With the support directory, you fetch our code and you can still build without going through the whole dependency mess
18:28 #navit: < genesis> ie or too lazy to package for the target
18:29 #navit: < genesis> i spend days to package mbrola to nixos to offer clean french support for espeak navit
18:29 #navit: <@KaZeR> the target maintainer argument makes sense for linux platforms where we hope for someone to properly build a package for a given distro, but for win* this will never happen, it's on us
18:30 #navit: < genesis> 3rd party paradigm has no end, why not put gtk2 and qt and whatsoever
18:30 #navit: < genesis> i don't want to flameware on that stuff at the age of 35.
18:31 #navit: <@KaZeR> > 3rd party paradigm has no end, why not put gtk2 and qt and whatsoever
18:31 #navit: <@KaZeR> true
18:31 #navit: <@KaZeR> > at the age of 35
18:31 #navit: <@KaZeR> you're dragging our average down! :)
18:31 #navit: <@KaZeR> tryagain: do you have an opinion on the support thing ?
18:32 #navit: < genesis> look my patches , in general i remove more than i add.
18:32 #navit: < genesis> when your software are too big, they failed, you're not a bank.
18:34 #navit: < genesis> and if the build if always same for your win32 target, there is binary called dll :) 
18:35 #navit: <@tryagain> KaZeR I agree, we have it because we want to support platforms which do not have a supported port of that library. Sometimes we include our port of a library to support. Sometimes it's simplier to invent gui_internal than port qt to WinCE.
18:39 #navit: < genesis> as a packager, i always see internal 3rd party has a thing i've to spend time to try to disable compiling on that instead of properly faild on missing dep
18:42 #navit: <@tryagain> genesis we could review rules which turn on support/* stuff on. For example, we could do it only if a specific platform is detected.
18:43 #navit: <@tryagain> so if a library-dev package is missing on some platform, you get a error. On the selected platforms, you have it turned on automatically. If you know what you do, you can enable it explicitly.
18:45 #navit: <@tryagain> I think that is what we have started from some years ago, but now mayb we indeed have too much detection magic.
18:45 #navit: < genesis> we've 8 years old cmake boilerplate.
18:46 #navit: < genesis> but anyway, i don't have solution for plateform i don't practice.
18:48 #navit: <@tryagain> what's wrong with cmake? Is our build system incompatible with current cmake?
18:48 #navit: < genesis> yes
18:49 #navit: <@tryagain> and the only solution is to upgrade it to a version which is incompatible with winCE stack?
18:50 #navit: < genesis> today it's complaining about pkgconfig rules, qt cmake files not founds etc, tomorrow they drop support.
18:50 #navit: < genesis> no there is no real incompatibility
18:51 #navit: <@tryagain> if we can support all platforms we support now, then why not upgrade?
18:52 #navit: < genesis> you can help, there is https://github.com/MaxKellermann/cegcc-build
18:52 #navit: < genesis> we a recent cegcc, you can try to up to latest ubuntu lts, and you will have a decent env
18:52 #navit: < genesis> s/we/with
18:54 #navit: < genesis> and follow  #652
18:57 #navit: < genesis> i want all the target on same LTs and we unify the image , so to save time, all pre-requi has to be build on the image
18:59 #navit: < genesis> and don't write complicated recipe on circleci or dockerfiles, call navit script if possible and better, call txt file with variables
18:59 #navit: <@tryagain> Is our wince compiler suite  incompatible with current ubuntu lts?
18:59 #navit: < genesis> i donno
19:00 #navit: < genesis> not try.
19:00 #navit: < genesis> understand me, i don't have wince hw , we have to promote people maintener of target
19:01 #navit: <@KaZeR> i can have a look at the cegcc-build you shared sometime this week
19:02 #navit: <@KaZeR> we updated our build system about a year ago and it was a nightmare to get it to work on an up to date system, because most of the dependencies of cegcc were badly outdated
19:02 #navit: < genesis> coord with jkoan he started something
19:03 #navit: < genesis> i speak with cirrus (max) so he updated the submodules this morning
19:03 #navit: <@tryagain> actually we could start with our current cegcc. IIRC it has everyting it needs to run inside it, so most probably  it will survive ubuntu upgrade.
19:05 #navit: <@tryagain> I suggest check if it would work out of the box with an old suite, and then choose our way, depending on results.
19:06 #navit: <@tryagain> if somebody can compile a binary for wince, somebody other could test it.
19:06 #navit: <@KaZeR> > if somebody can compile a binary for wince
19:07 #navit: <@KaZeR> exactly the point of circleci :D
19:07 #navit: <@tryagain> sure
19:12 #navit: < genesis> i don't have pb here, but upgrade the builder OS version create pb about ...
19:12 #navit: < genesis> guess what ? 
19:12 #navit: < genesis> cmake.
19:12 #navit: <@tryagain> btw we have wince build with cmake 3.10.2 here are logs http://legacy.navit-project.org/logs/navit/wince_cmake/svn/navit-svn-.ok
19:13 #navit: < genesis> yes that's why it's not my priority
19:13 #navit: <@tryagain> this is a package http://legacy.navit-project.org/navit/wince_cmake/svn/navit-svn-.zip
19:13 #navit: < genesis> sorry i'm a bit lost && tired && drunk
19:14 #navit: < genesis> just want a people say he will do it for n target
19:15 #navit: <@KaZeR> genesis: don't worry we are not asking you to fix all of the legacy issues :)
19:15 #navit: <@tryagain> genesis i'm not sure we'll fing such a guy before starting it. But most probably somebody would fix it if we face problems. So try. Again and again :)
19:16 #navit: <@KaZeR> :D
19:16 #navit: <@tryagain> *find
19:16 #navit: < genesis> i've to learn about docker since i was a qemu-kvm guy
19:17 #navit: <@KaZeR> tryagain: talking about things that we should try again, we still need to upgrade/update the map building service
19:17 #navit: <@KaZeR> genesis: feel free to ask any question, a few of us here are quite familiar with it
19:17 #navit: < genesis> hum for download xml.bzipped file ?
19:17 #navit: <@KaZeR> ?
19:19 #navit: < genesis> http://maps9.navit-project.org/ ?
19:20 #navit: <@tryagain> KaZeR we actually have upgraded the OS on map servers. There's still an issue, probably with xen settings (gnttab_max_frames) which prevents us from running current kernel.
19:20 #navit: < genesis> my bad it's bin directly
19:21 #navit: < genesis> was impressed how pbf -> bin was so long
19:21 #navit: < genesis> on a small faggot country as france
19:22 #navit: < genesis> maptool made perhaps 25 minutes
19:22 #navit: <@tryagain> pbf stores data in a way which is not good for random fetching. bin is a special dadabase file which has indices
19:24 #navit: <@tryagain> pbf has all osm nodes in one part of file, all ways in another. Ways data does not have coordinates, only references to node numbers.
19:24 #navit: < genesis> but xml is way faster in my head
19:24 #navit: <@tryagain> osm xml is organized the same way 
19:25 #navit: < genesis> i emulate a sample_map option in the nixos package to have a map and test maptool in the build
19:25 #navit: <@tryagain> as well as o5m
19:26 #navit: < genesis> https://github.com/NixOS/nixpkgs/blob/b8b71e26ed39449747785036aa0dad01edef2e67/pkgs/applications/misc/navit/default.nix
19:26 #navit: <@tryagain> actually, the fastest format for maptool is o5m. 
19:26 #navit: < genesis> my latest merged nixos recipe for nixos, look i've to fix glib and other missing linker 
19:26 #navit: < genesis> that's a part of why i fix thing in the build system :)
19:27 #navit: < genesis> i don't know about o5m, have to look that stuff.
19:28 #navit: < genesis> was impressed testing gpxseen, this software men should be contacted 
19:28 #navit: < genesis> i donno if we could split navigation intel from our software, but for me, the best softwares are the one that are capable to split in library to be shared the feature that make them unic
19:29 #navit: < genesis> for this i've to move stuff from main cmakefiles to be closest of the target source
19:30 #navit: < genesis> s/gpxsee
19:32 #navit: < genesis> i've some performance issue too with navit
19:32 #navit: <@tryagain> navit is modular, it has a few interfaces to communicate with other softwares. If you like gpxsee, and like navit, you could try too cross them :)
19:33 #navit: < genesis> we have to fix our issue before imagine such thing yeap
19:34 #navit: < genesis> but yes, i like the idea
19:34 #navit: < genesis> our qt gui is not used i think, i drop support by default since it has so much trouble
19:35 #navit: < genesis> people here seems to target gui_internal for embedded devices
19:35 #navit: <@KaZeR> genesis: qt4 or qt5?
19:35 #navit: < genesis> qt5, forget about qt4, noone want to support here nowadays
19:36 #navit: < genesis> i don't say it's totaly broken, just have to fix the qt-paint things and other stuff
19:37 #navit: <@KaZeR> yeah qt5 is currently a POC that requires more work but i think that we will be able to build something really nice with it
19:38 #navit: < genesis> gpxsee is 100% qt5, i don't understand why people doesn't join existing software
19:39 #navit: < genesis> (notice : it's not a navigation soft)
19:44 #navit: <@KaZeR> genesis: one thing to remember is that navit was first release in 2006. things were way different back then :)
19:44 #navit: < genesis> and noone provide the stuff for a navigation software , isn't it ?
19:45 #navit: <@KaZeR> yep, navit was the first open source vector based navigation software
19:46 #navit: <@KaZeR> there was gpsdrive, but since it was raster based, there was no navigation possible
19:49 #navit: < genesis> tangogps perharps 
19:49 #navit: < genesis> so we have a lot of viewer software and no navigation 
19:50 #navit: < genesis> best we have to focus on is to provide navigation software, not many gui and so
19:51 #navit: < genesis> i'm a qt fan, i'm on lxqt desktop, but i use gtk navit, i don't care, we have to focus on navigation
19:51 #navit: < genesis> i can't pick the right address in the location menu, it's always pick the first
19:52 #navit: < genesis> THAT is where i want to spend time, but hey, we have to do our duty, to make fix easier and permanent
19:53 #navit: < genesis> because build failure can introduce bad binary and byg
19:53 #navit: < genesis> bug
20:40 #navit: <@KaZeR> i also really like qt. it's really portable and provides some good UI foundations
20:40 #navit: <@KaZeR> gtk navit : you mean the gtk UI or the gtk graphics ?
20:49 #navit: <@tryagain> KaZeR I'm thinking if I should fix versioning on legacy nightly builds. Do we have some means to get monotonically increasing version number as output from cmake or git? Or better stick to something like navit-<builddate[time]>-<top-git-commit-hash>?
20:56 #navit: <@KaZeR> well we could use something similar to what we use for the play store updates which is basically the build date
20:56 #navit: <@KaZeR> what do we use the legacy nighly builds for?
20:56 #navit: <@KaZeR> afaik all builds have been ported to the new CI pipeline no?
20:56 #navit: <@KaZeR> excepted stuffs like openmoko, but this project is dead anyway
21:08 #navit: <@tryagain> well, it was useful today to understand that wince build is possible on current cmake :)
21:09 #navit: <@tryagain> also we use it to build maptool which we use to build planet.bin for our map servers
21:09 #navit: <@tryagain> version numbers are not actually needed for those purposes though :)
22:00 #navit: <@KaZeR> indeed. and we could build a docker container for the maptool processing, to make it easy to replicate
23:44 -!- xenos1984 [~xenos1984@22-164-191-90.dyn.estpak.ee] has quit [Quit: Leaving.]
--- Log closed Wed Sep 05 00:00:40 2018