--- Log opened Fri Jan 11 00:00:38 2019
01:29 -!- mvglasow [~mvglasow@dslb-088-067-043-080.088.067.pools.vodafone-ip.de] has quit [Quit: Leaving]
06:06 -!- xenos1984 [~xenos1984@2001:bb8:2002:200:6651:6ff:fe53:a120] has joined #navit
06:06 -!- mode/#navit [+v xenos1984] by ChanServ
06:08 #navit: <+jkoan> Hi mvglasow
06:09 #navit: <+jkoan> Interestingly I looked into making navit up to date on fdroid as well.
06:11 #navit: <+jkoan> I closed a log opened merge request to rework it with your script, but then I stuck by setting up a virtual machine to use the fdroid build and so on.
06:13 #navit: <+jkoan> As for how often we should update, Kazer and I decided to have a last version file on our download page, which we can edit, so we don't lose control when releases on fdroid come out.
06:13 #navit: <+jkoan> You can see my changes here: https://gitlab.com/fdroid/fdroiddata/merge_requests/2855/diffs
07:31 -!- naggety [~naggety@151.red-95-127-94.dynamicip.rima-tde.net] has joined #navit
08:06 -!- genesis [~genesis@unaffiliated/genesis] has joined #navit
14:02 -!- naggety [~naggety@151.red-95-127-94.dynamicip.rima-tde.net] has quit [Quit: Konversation terminated!]
15:09 -!- xenos1984 [~xenos1984@2001:bb8:2002:200:6651:6ff:fe53:a120] has quit [Quit: Leaving.]
16:27 -!- mvglasow [~mvglasow@dslb-088-067-043-080.088.067.pools.vodafone-ip.de] has joined #navit
16:28 #navit: < mvglasow> Hi jkoan
16:28 #navit: < mvglasow> Thanks for the update, just to clarify: do we want to publish anything that has a tag? Or just specific tags?
16:29 #navit: < mvglasow> For example, I see a tag named v0.5.3 (which should probably get published), and a newer one names Sailfish-v0.5.3-1, do we want that one published as well?
16:30 #navit: < mvglasow> Also, what about release candidates (e.g. v0.5.1-rc2)? Should they go on F-Droid?
16:31 #navit: < mvglasow> F-Droid can do some pattern matching on versions, e.g. I could specify v%v, which would include anything that starts with "v", e.g. v0.5.3 but not Sailfish-v0.5.3-1.
16:32 #navit: < mvglasow> It would also include v0.5.1-rc2; if we don't want that, we would have to add an exclusion regex to skip anything ending in -rc*.
16:32 #navit: < mvglasow> Good news is that tags are also what I use for my other projects.
16:33 #navit: <+Navit> <jkoan> we can publish chatever we want by putting it into this file: https://github.com/navit-gps/download-center/blob/master/_data/version.yml this updates the webpage and fdroid will download this site
16:34 #navit: <+Navit> <jkoan> *whatever
16:35 #navit: <+Navit> <jkoan> but for the pattern what should be mached, i an really mutch open. I did it only so it should work, bin this was probably not the optimal way
16:35 #navit: < mvglasow> does F-Droid support the version.yml logic?
16:35 #navit: < mvglasow> or is that something we have built around it?
16:44 #navit: <+Navit> <jkoan> I build it. The yml file is processed by jekyll (github pages) and publishes a json file. Fdroid downloads the json and I wrote a regex which filters version code and version name because fdroid does only support something like this on there "Update Check Data" field
16:44 #navit: <+Navit> <jkoan> The json file gets published here BTW http://download.navit-project.org/api/version.json
16:47 #navit: <+Navit> <jkoan> I manly build this file as a compromise on what they provide to detect updates automatically: https://f-droid.org/en/docs/Build_Metadata_Reference/#UpdateCheckMode
16:50 #navit: < mvglasow> What is the logic on the F-Droid side for processing this JSON? None of their docs says anything about it.
16:51 #navit: <+Navit> <jkoan> when you look at line  636 and following of my closed PR there is how its processed: https://gitlab.com/fdroid/fdroiddata/merge_requests/2855/diffs its just regex
16:53 #navit: < mvglasow> now I see it, all right
16:54 #navit: < mvglasow> has this mechanism been tested successfully?
16:54 #navit: <+Navit> <jkoan> did you alrerady have a VM to test fdroid buils? I dident managed to set one up in a short time
16:54 #navit: < mvglasow> unfortunately not
16:54 #navit: <+Navit> <jkoan> so no, i dident tested the build, but the update detection worked
16:54 #navit: < mvglasow> tried a while back but did not succeed
16:55 #navit: <+Navit> <jkoan> i thryed the update detect with this docker command: jan@jan-ThinkPad-T430:~$ docker run --rm -u $(id -u):$(id -g) -v $(pwd):/repo -v /home/jan/.bin/android-ndk-r11c/:/android-ndk-r11c registry.gitlab.com/fdroid/docker-executable-fdroidserver:latest build org.navitproject.navit
16:55 #navit: < mvglasow> ok, update detection is what I need, so I’ll just copy the respective sections from your merge request
16:55 #navit: < mvglasow> tigether with ny build logic
16:55 #navit: < mvglasow> *together with my
16:57 #navit: <+Navit> <jkoan> but the build will not work since many tools are missing in the image, and i had no time to bump the image up, to install additional tols, but that would probably what i want to try. Use there image as a base image and install cmake and all other things that we need to build navit
16:57 #navit: < mvglasow> that's what I am currently working on
16:58 #navit: < mvglasow> biggest obstacle is that Coverity us currently down and we're not getting any automated merges into trunk
16:58 #navit: < mvglasow> *into master (from trunk)
16:59 #navit: < mvglasow> would it break anything if I just worked around this by merging trunk into master manually (after verifying CI has passed successfully otherwise)?
16:59 #navit: <+Navit> <jkoan> in my oppinion we should remove Coverity since it often makes problems in the way we use it as of today. probably we could reintroduce it with github actions later on
17:00 -!- xenos1984 [~xenos1984@b158-0638-8ee6-7806-8780-87e7-07d0-2001.dyn.estpak.ee] has joined #navit
17:00 -!- mode/#navit [+v xenos1984] by ChanServ
17:00 #navit: <+Navit> <jkoan> i think that should be okay
17:00 #navit: < mvglasow> makes sense, in fact I am not too sure having the build depend on it is a good idea
17:00 #navit: < mvglasow> especially if the scan result is not taken into account
17:02 #navit: <+Navit> <jkoan> the scan results are uploaded to Coverity for analysis, and we even found some bugs from there as far as i know
17:04 #navit: < mvglasow> sure, that is a good thing to have, but so far it has been like this:
17:04 #navit: < mvglasow> scan and upload completes and Coverity returns all sorts of red flags - everything fine, CI passes and we update master
17:05 #navit: < mvglasow> scan or upload fails - panic, CI fails and master is not updated
17:05 #navit: <+Navit> <jkoan> yes, its probably not god implemented right now
17:05 #navit: < mvglasow> so either we trigger the scan but at the most raise a warning if it fails
17:06 #navit: < mvglasow> or we analyze the scan results and have CI fail if any errors are found
17:06 #navit: < mvglasow> anyways, for the moment I will just disable it and open a ticket with the details
17:07 #navit: < mvglasow> and get in touch with the F-Droid guys, to see if there's a way to test the build
17:07 #navit: < mvglasow> they seem to have had some issues with their CI lately
17:07 #navit: <+Navit> <jkoan> In my opinion we should even not have it as path of the automatic merging. BTW, does automatic merging makes any sense as well?
17:08 #navit: < mvglasow> automatic merging is not even a bad idea:
17:08 #navit: < mvglasow> commit to trunk, which triggers CI
17:08 #navit: < mvglasow> if CI tests pass, merge into master
17:08 #navit: < mvglasow> else don't
17:09 #navit: < mvglasow> that way we keep the obviously buggy stuff out of master, which gives us at least a minimal guarantee of always having a functional branch
17:09 #navit: <+Navit> <jkoan> Yes, but why should you upload something untested to master/trunk instead of a own branch?
17:10 #navit: < mvglasow> except that tha name trunk is poorly chosen (legacy, I know); dev would be a better choice IMHO
17:11 #navit: < mvglasow> uploading stuff that has not been thoroughly tested happens all the time, humans do make mistakes and some may not even have the means to test everything
17:11 #navit: < mvglasow> so a standard suite of tests makes sense
17:12 #navit: < mvglasow> of course, there can also be false positives from CI
17:12 #navit: < mvglasow> a way to override this (after carefully checking things) would be good
17:14 #navit: <+Navit> <jkoan> yeah, unit tests whould be really greate....
17:15 #navit: <+Navit> <jkoan> in my python things at work i have a lot of them, but i dont have any idea how i would add some to navit, or even c code in general. and even after that i dont know if the rerally modular aproche of navit would help here of is a deal braker
17:16 #navit: <+Navit> <jkoan> in theory it should be possible to test every plugin on its own, but then callbacks and such stuff will probably not work and things are uninitalisized and so on..
17:18 #navit: < mvglasow> I have little experience with that kind of stuff, but I understand you would provide a dummy framework to test the plugins, and dummy plugins to test the framework
17:22 #navit: <+Navit> <jkoan> that whould also be a soulution, yes. In Python i test every class on its own, because they can exit without other things. if i need to pass a objekt of a other class then i generate them in the test case, but test them invidually also. If i think that in navit if could be done simular the first thing we would need to test would be the navit instance itself or the util functions
18:18 #navit: <+ilovekiruna> hi jkoan, hi mvglasow
18:32 #navit: < mvglasow> hi
18:32 #navit: <+ilovekiruna> jkoan: my collection of mobiles is also growing. Hope in the coming months we can revive the device farm idea again
19:00 #navit: <+Navit> <jkoan> ilovekiruna: yes, i hope so to, but i havent find any prebuild solutions, and writing everything from ground up is a lot of work
19:01 #navit: <+ilovekiruna> jkoan: I would see it like that. For the distributed execution we use a of the shelf CI, like jenkins, buildbot, ....
19:02 #navit: <+ilovekiruna> only thing we need to develop is the test script
19:02 #navit: <+ilovekiruna> which we partially could base on my python scripts
19:04 #navit: <+ilovekiruna> what do you think?
19:24 #navit: < mvglasow> PR to disable coverity is up, https://github.com/navit-gps/navit/pull/730/
20:13 #navit: <+Navit> <jkoan> ilovekiruna: probably this could also be interesting: https://openstf.io/
20:13 #navit: <+Navit> <jkoan> mvglasow: will review soon
20:16 #navit: <+Navit> <jkoan> okay to merge
20:23 #navit: <+ilovekiruna> jkoan: sounds great
20:23 #navit: <+ilovekiruna> will test it now
20:44 #navit: <+ilovekiruna> jkoan: seems like not 100 percent usable for us
20:44 #navit: <+ilovekiruna> seems to rely on osx :'(
21:25 #navit: <+ilovekiruna> need to roeect myself
21:25 #navit: <+ilovekiruna> I think it works
21:32 -!- zintor [55d84f3f@gateway/web/freenode/ip.85.216.79.63] has joined #navit
21:32 #navit: < zintor> hi @all
21:33 #navit: < zintor> a question regarding POI icons:
21:34 #navit: < zintor> I have a svg POI icon, document size 22x22px
21:36 #navit: < zintor> it is small shown
21:37 #navit: < zintor> as we have zoom levels
21:37 #navit: < zintor> is there a chance to resize the svg regarding the zoom level?
21:41 #navit: < zintor> if I change the document size of svg, nothing changes
21:41 #navit: < zintor> it is always very small
21:42 #navit: < zintor> if I use a png with 48x48px it is bigger shown
21:43 #navit: < zintor> so question is: does Navit recognise document size? or is it down-sized?
21:43 #navit: < zintor> I remember, that KaZeR mentioned something with huge svg poi, because of wrong document size.
21:44 #navit: < zintor> maybe because of this, the svgs are always same size? regardless of document size?
21:54 #navit: < zintor> cya all
21:54 -!- zintor [55d84f3f@gateway/web/freenode/ip.85.216.79.63] has quit [Quit: Page closed]
21:55 #navit: <+ilovekiruna> jkoan: it resolves another problem i have :-)
21:56 #navit: <+ilovekiruna> thanks a lot
22:17 #navit: <+ilovekiruna> with it you can manually control the devices
22:17 #navit: <+ilovekiruna> but i think one had to couple it with sth like adium, selium or any other automation framework
22:30 #navit: <+Navit> <jkoan> Ilovekiruna how did you set it up? On a virtual machine?
22:36 #navit: <+ilovekiruna> jkoan: just at my local linux machine
22:36 #navit: <+ilovekiruna> install the dependencies, and then run it
22:37 #navit: <+ilovekiruna> but you need to be careful about the nodejs version
22:37 #navit: <+ilovekiruna> it just supports up to version 7
23:04 -!- mvglasow [~mvglasow@dslb-088-067-043-080.088.067.pools.vodafone-ip.de] has quit [Quit: Leaving]
--- Log closed Sat Jan 12 00:00:39 2019