[01:13:44] *** Quits: DuncanDo (~DuncanDo@pool-108-26-184-80.bstnma.fios.verizon.net) (Quit: Leaving) [04:05:29] *** Joins: xenos1984 (~xenos1984@169-100-191-90.dyn.estpak.ee) [04:05:29] *** ChanServ sets mode: +v xenos1984 [08:25:31] *** Quits: xenos1984 (~xenos1984@169-100-191-90.dyn.estpak.ee) (Ping timeout: 258 seconds) [10:20:20] *** Joins: xenos1984 (~xenos1984@169-100-191-90.dyn.estpak.ee) [10:20:20] *** ChanServ sets mode: +v xenos1984 [10:29:59] @ilovekiruna I did a test run of openstf today, and I think this I quite cool. I only don't know if it's usable for tomtom and other devices then android [11:01:04] Openstf has many submodules. It should be possible to plug them together so that there is one frontend and every team member who want to host android devices need to get a raspberry Pi to run a "worker", which connects to a VPN to access the master internally. This way the devices can stay secure (prosumably) [13:55:31] *** Quits: Number6 (~number6@zoidberg.geoghegan.me) (Remote host closed the connection) [13:57:49] *** Joins: Number6 (~number6@zoidberg.geoghegan.me) [13:57:49] *** ChanServ sets mode: +o Number6 [16:21:58] hi there [16:24:03] genesis: regarding https://github.com/navit-gps/navit/pull/710 i asked a clarifying question that wasn't answered [16:24:31] <05jkoan> hi @KaZeR [16:24:59] documentation isn't reinventing the wheel. There's a lot of good content in our wiki, but 1) it's poorly organized because it has been contributed by maybe people without review and 2) or wiki is getting killed by spammers [16:25:31] <05jkoan> yes 😄 [16:25:31] if you have a good software but no documentation about how to set it up (especially something that doesn't yet have a configuration wizard like navit) then you're screwed [16:25:53] pretty much all of our new users get stuck at getting a empty screen when starting navit the first time [16:26:10] so we 1) need a wizard to make this easier and 2) need to document how to use it and tailor its config [16:30:37] or event remove the need to do configuration ;) [16:44:05] if you have no contributor because you're lacking of reviewing, lying about be more important things and in reallity discussing about add a framework to test image on tomtom, setup new feature in discord or write a ascii output [16:45:53] people should be free to work on what they are interested in. Discussing something doesn't mean that it'll be done [16:46:08] i had a use case to have spotify integrated in navit because i wanted it for my own car [16:46:13] did anybody else care? nop [16:46:22] does it matter? nop. i wanted it, so i made it [16:47:12] re: tomtom : what are our target platforms? I don't think that it's platforms like IOS. I think that tomtom and wince are actually good target platform [16:47:29] because users of these platforms get pissed at not getting map updates [16:47:48] so yeah, a framework to test image is important because it'll help improve the overall quality [16:47:57] you said it yourself : tomtom doesn't work out of the box on your device [16:48:13] probably because the ttysystem image got borked at some point. But nobody noticed it until recently [16:48:29] i told you month ago [16:48:46] that doesn't work. [16:50:14] nobody noticed because nobody use it because it just doesnt work [16:51:19] https://github.com/navit-gps/NavitTom/issues/3 [16:51:29] but jkoan doesn't care other issues [16:52:16] never answer, looking data on merge request on navit since month, only people with write access merging their own stuff [16:56:16] > i told you month ago [16:56:52] without issues to track it, it's pretty much guaranteed that i'll forget it [16:57:15] that why 2 or 3 years ago we invested a LOT of time setting up circleci [16:57:32] now we have automated builds for pretty much all platforms, and we can change things more confidently [16:57:43] is it perfect? absolutely not [17:30:03] jkoan: i had a quick look at stf's website. It looks like it's not automatable though [17:30:10] too bad, my wife could use this for work too [17:30:48] <05jkoan> Actually you can as you can connect to the adb [17:31:08] so you need appium on top of it or something like that, correct? [17:31:19] and stf only really does the farm management [17:33:46] <05jkoan> Yes, and it should be possible to host the device workers on other locations then the server [17:34:07] <05jkoan> I think sft is mostly for human testing things [17:37:26] genesis: I have seen the issue, but I have another scope currently then fixing this. [17:38:28] when i was speaking of tomtom doesn't working, i see in my log, you were rewriting maptool [17:39:27] now you're on automatic testing farm, why not. [17:41:13] What do you want people to do if then don't have more time? Answer on every single thing "noticed, have no time currently, see you in a year"? We aren't a large team, if you want support for everything just buy us more man power who works full time on Navit. Everyone may do what he wants. [17:42:38] Also I write things about the device farm, because I collect informations in the time when I can't work on other things (sitting in the tram or whatever) this doesn't mean that's the only thing I am doing. We have so many things to do... [17:43:20] i've worked on navit full time for few weeks, now it sounds like big wasting time [17:44:29] yesterday i was building the new toolchain for wince to free the way to upgrade our test infrastructure, but not all things are as easy as you probably thought. We dont want to drop support for things, this is simply not how we want to treat things [18:06:12] genesis: i really don't think that it's a big waste of time. it's just that once you've done the first 90%, sometimes the last 10% that you need from others are difficult too [18:06:18] cmake is a good example of that [18:06:37] let's have a look. which PR are you the most frustrating about? [18:06:48] my point is not to argue, but to break down what's left to do so that we can merge it [18:07:10] backport cmake 3 on your old stuff if you're not able to update all in one [18:10:48] https://github.com/navit-gps/navit/pull/659 look the failure [18:11:09] should it be so much time to look at why it finaly doesn't find navit.exe [18:13:26] i don't use windows so i won't test all of it easily, people claims to maintain support for OS have to not block others that try to improve for their own [18:14:17] a day you'll wait so long to update the build process that it will be not compatible with linux, let's see. [18:15:09] yep. "mingw32 -> mingw-w64" is actually much harder than it sounds [18:15:20] here's where i left it off : https://gist.github.com/pgrandin/e5b5e38535f8b0b75a793f12eec06414 [18:16:04] if you have a moment to spare, i'd definitely appreciate your input on why this toolchain build is failing [18:20:33] issue for #659 probably found (no exe extension) [18:21:21] hehe it's big recipe, mine for another project https://github.com/bignaux/Magick2CPC/blob/master/.travis.yml :') [18:22:08] it looks like i missed the actual problem here actually [18:23:29] for PR#659 it seems that the build is failing because the file is not found, because navit.exe is searched, but navit is produced. The exe suffix is missing [18:23:56] #SET(CMAKE_EXECUTABLE_SUFFIX ".exe") [18:23:59] so my fault here [18:24:19] but since i don't remember it's so long time, i perharps read something it was default [18:24:28] let try to uncomment [18:24:36] thx :-) [18:25:50] i will test the build right away when it passed (WinCE) [18:26:25] kazer: what do you think about my comment on PR#710? [18:26:26] hum [18:26:54] btw look it's only failed on wince [18:26:59] since it's not upgraded . [18:27:37] thats possible, lets try to fix this for now and update the chain in a next step [18:28:11] i should try to set up only for wince script [18:29:15] would be nice if this would work, yes, i am already preparing the wince device [18:31:33] jkoan: re #710, i think that it would be better to have this part of the CI process. If it's manual, we'll fuck up at some point [18:32:53] yeah, i know, but the current approach has the problem that we cant provide good tarballs, and build on a none dev enviroment (eg. no git installed for example) [18:33:31] we can still generate a curated tarball from the CI, no? [18:33:44] state of the art distro build in a sandbox that has no such git or network [18:33:55] to avoid fetching hasardous content [18:34:19] genesis, yes, thats exacly what i was meaning [18:34:21] guix, nixos , and so [18:34:44] it would be so easier to fix thing if you were nixos enlightned :d [18:35:07] enlighten us :) [18:35:56] we could build the tar on ci, but you (kazer) should remember our last tomtom download debacle, right? [18:35:58] but previous linux gen, distro source as archlinux or gentoo, has some commodity than very old stuff (redhat debian and derivated) don't. [18:36:39] jkoan: don't count on me remembering stuff! [18:37:06] different browser different hashsum ... [18:37:45] ah, yeah odd one [18:40:59] the ci senety chack failed (we really need to fix the check) [18:42:17] seems to be online about line length [18:43:17] yes, but those files where not changed by him, i will deactivate this chack for now, to reenable it really soon, just let us finish the PRs first [18:43:25] agreed? [18:43:42] give me one sec [18:44:32] was trying to rebase, but of course, error. [18:44:50] the Problem is the difference listing in scripts/ci_sanity_checks.sh which does strange things on files which are not actually changed [18:48:57] btw genesis your PR still shows as WIP, is that intentional? [18:49:21] was for discussing [18:49:48] no answer in 9 months. [18:50:13] it's not our record ;) [18:50:52] no glory, i contribute many project, and all free time, they are not like that [18:51:01] sanity checks passed. nice [18:51:03] btw i fixed the sanity :) [18:51:16] nice :D how? [18:51:23] git rebase [18:51:40] erm [18:51:43] https://github.com/navit-gps/navit/pull/659/commits/4a66b802b528a20fcc937750fb5e69399a3b5a89#diff-f3eec31c9a0f530eda27080a54d7a207 [18:52:03] wanted to say the same, but we can fix this easily :-) [18:52:33] hum fking git, this part is not very good in it. [18:53:25] ( git am --show-current-patch i don't get it) [18:53:33] before i begun to work here on navit i was also way worth in git, and even now i am not perfect in it ;-) [18:54:27] just edit the buzild_win32 file have the fixed script and recommit it [18:56:06] caneled the old running CIs to save time ;) [18:57:38] but do you agree with the attempt of the pR ? [18:57:50] yep [19:02:08] wince build looks good [19:02:16] now: test [19:05:08] yeap if you've a wince target, i don't [19:05:47] as i said before i already prepared the device ;-) files already copying [19:06:04] for unsupported and old target, i'm more in z80 target, was hacking some gameboy stuff this days [19:08:10] said that navit on z80 does not make real sense. Or is there any device with gps? :D [19:08:27] *** Joins: DuncanDo (~DuncanDo@pool-108-26-203-56.bstnma.fios.verizon.net) [19:08:52] hi DuncanDo [19:08:59] hey jkoan [19:09:39] amstrad cpc had a serial port [19:10:05] in the old times, i connect it to my minitel to download software over the phone line [19:10:35] thise sounds on connections are so mutch nostalgic :-) [19:14:45] kazer, genesis: hers the wince log: https://pastebin.com/9bHFjfWc [19:22:00] can't tell, seems to run. [19:22:21] and instantly crashes [19:24:01] okay, config was broken [19:25:54] kazer, okay, to merge [19:28:04] jkoan: nice. teamwork makes the dream work! [19:28:42] #710 ? [19:29:00] easy one [19:29:00] #659 [19:29:10] merge 659 and we go 710 [19:29:14] i think genesis was asking about the next one [19:29:17] yeah :) [19:29:28] jkoan: feel free to merge. you did the review and test [19:29:35] since you merge, i rebase 710, i fix and we discuss [19:30:25] btw , it's version or git version, but not version+git version [19:31:03] if you rethink about it, a git rev means nothing with version [19:32:09] and it's a +15 −96 patch, like i like it. [19:36:48] well regarding git it should actually probably be a commit [19:36:59] it's something that comes from our svn time IIRC [19:37:29] i think that it's still useful to have the version (as in semver version, from the release) as part of what we display there maybe? [19:37:48] because you can't really infer the release from the git commit without looking for it [19:38:05] i don't understand [19:38:18] yeah maybe we're not talking about the same thing [19:38:23] do you have an example of what you meant? [19:38:36] btw the code here has many changes, hum [19:38:57] if you're building a git rev, put NAVIT_VERSION as git+rev [19:39:13] if it's a release, you just put the NAVIT_VERSION of the release [19:40:20] so yeah we're talking about the same thing. I meant to say that "navit 0.5.3+git:0c152ff" has the advantage of instantly allowing us to see how old that code is [19:40:22] i did a lot of packaging since 15 years, look my github stat, the only real case we should care is what i've exposed [19:40:34] but i don't feel to strongly about that [19:40:49] release should be proper, with no +git thingy [19:41:06] yeah i agree for the release. i was more talking about builds from git [19:41:23] because you're suggesting to ditch the 0.5.3 part if we build from a git checkout right? [19:41:50] for build from git fix NAVIT_VERSION to git revision [19:42:01] yes [19:42:14] since it's not 0.5.3, that doesn't mean anythong [19:42:24] if you build on TAG and not revision, another story [19:42:44] on nixos, i use a prefetch git on tag [19:43:12] so that's the very same of the release source, other are not. [19:44:29] https://github.com/NixOS/nixpkgs/blob/b8b71e26ed39449747785036aa0dad01edef2e67/pkgs/applications/misc/navit/default.nix#L26 [19:45:14] so fetchFromGitHub will automagically download tarball [19:45:22] i think that this is fine [19:46:16] to sum up, if you CMAKE_BUILD_TYPE=Release , so you don't want +git [19:46:37] if not, you need it, but not mention of version. [19:46:58] and btw, you need git rev but not git binary [19:47:38] because next gen distribution try to remove fetching tool from building phase [19:48:13] jkoan: thoughts about this? i can't think of a reason to not ditch the release part if we build from a git commit [19:49:42] and remember, the priority case is release [19:50:11] yep i think that this makes sense [19:50:47] let me fix the gui_internal_menu.c [19:50:54] i donno what people is making here [19:51:22] the problem when PR are too old [19:52:08] char *version_text=g_strdup_printf("Navit %s",NAVIT_VERSION); [19:52:10] not a fan. [19:52:21] but let it be [19:53:48] i'll fix that later. [19:57:37] and btw this PR doesn't remove git prefix, it just simplify before we do it. [19:57:53] kazer, you mean on Release=Veraion, on Debug=Commit hash? [19:58:40] but as a workaround, it lets packager define NAvIT_VERSION so package will have not prefix. [19:59:22] my way to work ; let behaviour as it is, but permit people to fix stuff . [20:00:04] but if we're agree to go further, i can PR more logic break . [20:03:34] but since it involve to write stuff in #659 , i didn't want to do that on old script [20:05:50] it has to go in cmakelist. [20:07:39] but don't be too rough on this , because if we target cmake 3, we have new feature to set it well [20:08:19] would be time waste to spend too much on this, just simplify in the way to make easy to step forward. [20:09:55] #710 remove 2 files, #659 3 files [20:12:06] #651 4 files. [20:13:22] if i could write the build stuff on nix, that would be so many stuff :3 [21:21:35] *** Quits: xenos1984 (~xenos1984@169-100-191-90.dyn.estpak.ee) (Quit: Leaving.) [23:43:43] jkoan, are you going to watch "I am mother"?