--- Log opened Wed Mar 28 00:00:00 2018
00:33 -!- j_f-f [~quassel@rs-7.jff-webhosting.net] has quit [Ping timeout: 260 seconds]
00:41 -!- j_f-f [~quassel@rs-7.jff-webhosting.net] has joined #navit
02:46 -!- noradtux [~noradtux@2a04:4540:8c00:101::1] has quit [Ping timeout: 240 seconds]
02:51 -!- noradtux [~noradtux@134.101.151.188] has joined #navit
04:49 -!- xenos1984 [~xenos1984@2001:bb8:2002:200:6651:6ff:fe53:a120] has joined #navit
04:49 -!- mode/#navit [+v xenos1984] by ChanServ
06:22 -!- ilovekiruna [~ilovekiru@ip1f129b37.dynamic.kabel-deutschland.de] has quit [Quit: Konversation terminated!]
12:38 -!- ilovekiruna [~ilovekiru@wlanstaff504.wlan.tu-clausthal.de] has joined #navit
12:39 -!- mode/#navit [+v ilovekiruna] by ChanServ
12:56 -!- ilovekiruna [~ilovekiru@wlanstaff504.wlan.tu-clausthal.de] has quit [Ping timeout: 240 seconds]
14:31 -!- xenos1984 [~xenos1984@2001:bb8:2002:200:6651:6ff:fe53:a120] has quit [Quit: Leaving.]
15:03 -!- xenos1984 [~xenos1984@22-164-191-90.dyn.estpak.ee] has joined #navit
15:03 -!- mode/#navit [+v xenos1984] by ChanServ
16:42 #navit: <+jkoan> hi @all
16:54 -!- aerostitch [~aerostitc@c-67-164-55-119.hsd1.ca.comcast.net] has joined #navit
17:11 #navit: <+jkoan> hi aerostitch
17:13 #navit: < aerostitch> Hey jkoan
17:13 #navit: < aerostitch> how are you?
17:13 #navit: <+jkoan> i think good :D
17:14 #navit: <+jkoan> do you have some time?
17:23 #navit: < aerostitch> I can make some
17:23 #navit: < aerostitch> what's up?
17:24 #navit: <+jkoan> what do you think for: https://github.com/navit-gps/navit/pull/309 ?
17:27 #navit: < aerostitch> wow, that's a loooot of changes, I'll need a few mins to digest that :D
17:27 #navit: <+jkoan> currently this would generate 16 deb packages instead of one
17:28 #navit: <+jkoan> most of the changes are only in the CMakeList.txt to specify the component
17:30 #navit: <+jkoan> Component Unspecified=Main Package
17:32 #navit: < aerostitch> yeah.
17:32 #navit: < aerostitch> Note while I'm reading it: I think you can remove "PATTERN ".svn" EXCLUDE"
17:33 #navit: < aerostitch> now that we are on git
17:33 #navit: <+jkoan> oh yes, thx
17:34 #navit: < aerostitch> Wondering if that generates the main package as a virtual package that depends on all the others
17:35 #navit: < aerostitch> what we usually do in Debian when we split packages from an existing tool
17:35 #navit: <+jkoan> i think we can not depend on all packages
17:35 #navit: < aerostitch> is that we have the main package which has the same name as the old package and tha ships everything
17:35 #navit: <+jkoan> but i would also like this
17:35 #navit: <+jkoan> yes
17:35 #navit: < aerostitch> and the other packages are smaller
17:36 #navit: < aerostitch> the thing with not doing it this way is that when you upgrade you would loose functionnalities
17:36 #navit: <+jkoan> so the main package would become navit-bin and navit would be the virtual packe
17:36 #navit: < aerostitch> I mean the way it's done here
17:36 #navit: < aerostitch> yes
17:36 #navit: < aerostitch> or navit-common
17:37 #navit: <+jkoan> sounds good
17:37 #navit: < aerostitch> what they do in python is that they have one that is called python-minimal
17:37 #navit: < aerostitch> which contains the core
17:38 #navit: < aerostitch> and python which brings other packages
17:38 #navit: <+jkoan> (Y)
17:39 #navit: <+jkoan> but do you think there are to much packages?
17:40 #navit: < aerostitch> not sure
17:41 #navit: < aerostitch> Hold on a sec I was checking something
17:41 #navit: < aerostitch> for the smaller packages you will need to do something like that: https://salsa.debian.org/debian/gnome-shell-pomodoro/blob/master/debian/control (on the latest package)
17:42 #navit: < aerostitch> I mean the following part:
17:42 #navit: < aerostitch> Replaces: gnome-shell-pomodoro (<< 0.10.2-4)
17:42 #navit: < aerostitch> Breaks: gnome-shell-pomodoro (<< 0.10.2-4)
17:42 #navit: < aerostitch> https://cmake.org/cmake/help/v3.6/module/CPackDeb.html#variable:CPACK_DEBIAN_PACKAGE_REPLACES
17:42 #navit: < aerostitch> using that^
17:43 #navit: < aerostitch> for the dependencies you can use https://cmake.org/cmake/help/v3.6/module/CPackDeb.html#variable:CPACK_DEBIAN_PACKAGE_RECOMMENDS
17:43 #navit: <+jkoan> yes, this is one path which is not finished right now ;)
17:43 #navit: <+jkoan> did i remember right, you are also a debian package maintainer?
17:44 #navit: < aerostitch> yes I am
17:44 #navit: <+jkoan> so i randomly asked the right man :D
17:44 #navit: < aerostitch> lol
17:45 #navit: <+jkoan> i only known your a navit maintainer in the moment i asked :D
17:48 #navit: < aerostitch> I haven't touched the navit package in Debian yet and I'm more an infrequent contributor than a maintainer to be fair :D
17:48 #navit: <+jkoan> but you have the rights to do so ;)
17:48 #navit: < aerostitch> lol
17:49 #navit: < aerostitch> true :D
17:49 #navit: < aerostitch> so just as a recap you would have:
17:49 #navit: < aerostitch> - navit: virtual package
17:50 #navit: < aerostitch> - navit-minimal or common which would have the core
17:50 #navit: < aerostitch> - navit-bindings-python
17:50 #navit: < aerostitch> -navit-bindings-dbus
17:51 #navit: <+jkoan> okay, one important question: should the navit.xml be in the minimal package or in data?
17:51 #navit: <+jkoan> currently we would have navit-bindings as one package. So also split this one?
17:52 #navit: < aerostitch> Not sure if it's worth having several bindings
17:53 #navit: <+jkoan> probably in the future, but right now we only have verry little amount of bindings
17:53 #navit: < aerostitch> Navit doesn't work fine without navit.xml right?
17:53 #navit: < aerostitch> So it needs to be in the core package
17:53 #navit: <+jkoan> okay
17:57 #navit: < aerostitch> so navit, navit-minimal, navit-bindings, navit-graphics-cocoa, navit-graphics-egl, navit-graphics-gd, navit-graphics-gtk, navit-graphics-opengl, navit-graphics-qt, navit-graphics-sdl, navit-graphics-win32
17:57 #navit: < aerostitch> and then you have the same packages as graphics but for the gui
17:57 #navit: < aerostitch> and then a bunch of packages for maps
17:57 #navit: <+jkoan> yes
17:57 #navit: <+jkoan> yes
17:58 #navit: < aerostitch> I think you should probably merge the graphics and gui packages together
17:58 #navit: <+jkoan> ol or only gui-sdl and graphics-sdl (for example)?
17:58 #navit: <+jkoan> *all
17:59 #navit: < aerostitch> by graphics system so merge gui-sdl and graphics-sdl I would say
18:00 #navit: < aerostitch> I haven't looked much on the maps
18:00 #navit: < aerostitch> what's the difference between the different map stuffs
18:00 #navit: < aerostitch> ?
18:00 #navit: < aerostitch> it's to add maps support for garmin for example?
18:01 #navit: <+jkoan> yes
18:02 #navit: <+jkoan> there are multiple map formats which are supported on navit and every package could probide one type
18:02 #navit: < aerostitch> But does that really make sense not to have that in the core?
18:03 #navit: < aerostitch> I mean those are extremely light
18:04 #navit: <+jkoan> good question, for example "binfile" would make sense in the core, but for example garmin not because of the dependencies 
18:05 #navit: < aerostitch> my thoughts exactly
18:05 #navit: < aerostitch> I would say like navit-plugin-garmin
18:06 #navit: <+jkoan> sounds nice
18:06 #navit: < aerostitch> then the vehicles would not work without the graphics right?
18:06 #navit: <+jkoan> so main map drivers in core and specific ones in a plugin package
18:07 #navit: < aerostitch> correct
18:07 #navit: < aerostitch> I think the vehicles packages, like the gui ones should go in the corresponding graphics. What do you think?
18:07 #navit: <+jkoan> navit would work without vehicles :D 
18:07 #navit: <+jkoan> yes
18:08 #navit: < aerostitch> I mean the ones that are in separate packages in the pR
18:08 #navit: < aerostitch> like the iphone one should be probably in graphics-cocoa I guess
18:09 #navit: <+jkoan> i also think so
18:09 #navit: < aerostitch> same for the speech
18:09 #navit: < aerostitch> so instead of calling the packages navit-graphics-gtk maybe just navit-gtk
18:10 #navit: <+jkoan> yes, i will recognise everythink, thx for the help
18:10 #navit: < aerostitch> pedestrian is a plugin?
18:10 #navit: <+jkoan> yes
18:10 #navit: <+jkoan> only working on android
18:11 #navit: < aerostitch> k
18:14 #navit: < aerostitch> maybe also split j580 and pedestrian in their own packages
18:14 #navit: < aerostitch> like navit-plugin-j580
18:14 #navit: < aerostitch> more explicit
18:14 #navit: <+jkoan> okay (Y)
18:15 #navit: <+jkoan> and if we have this (and done a release) you would publish this under the same names on debian?
18:16 #navit: < aerostitch> I'll work with the current maintainer to do so yes
18:16 #navit: <+jkoan> thx for the reminder on github
18:16 #navit: <+jkoan> verry nice thx :)
18:16 #navit: <+jkoan> i will try to do as discussed in the next days
18:17 #navit: < aerostitch> ok thx
18:26 #navit: <+jkoan> like this? https://pastebin.com/ang2rmzQ
18:54 #navit: < aerostitch> so when you do `-> none`
18:54 #navit: < aerostitch> it means you don't build the debian package?
18:55 #navit: < aerostitch> like no iphone, maemo, windows packages for debian
18:55 #navit: < aerostitch> that does make sense
18:56 #navit: <+jkoan> yes, thos components are not available on debian (mostly because it dont make sense (for example win on debian
18:56 #navit: <+jkoan> )
18:56 #navit: <+jkoan> yes
19:07 #navit: < aerostitch> looks good then
19:19 #navit: <+jkoan> https://pastebin.com/cU4NTLCu this is what i have so far. how does this looks?
19:45 -!- ilovekiruna [~ilovekiru@ip1f129b37.dynamic.kabel-deutschland.de] has joined #navit
19:45 -!- mode/#navit [+v ilovekiruna] by ChanServ
21:01 #navit: <+jkoan> Ilovekiruna could you please review my last pr?
21:03 #navit: < aerostitch> jkoan espeak shouldn't be in core?
21:03 #navit: <+jkoan> Good question :x
21:04 #navit: < aerostitch> and speech-dispatcher too
21:04 #navit: < aerostitch> as it manages the speech plugin to use if I'm not mistaken
21:04 #navit: < aerostitch> right?
21:06 #navit: <+jkoan> I think those both are implications of spezific speech thinks. The interface for it should already be in the core
21:07 #navit: < aerostitch> hm...ok. I'd still keep it in core but if you prefer to keep then out, that's fine
21:07 #navit: < aerostitch> other question
21:08 #navit: <+jkoan> I'm not sure where we should put them. I will think about it
21:09 #navit: < aerostitch> gypsy is only for getting the gps position and uses dbus, should it be presented as a plugin ?
21:10 #navit: < aerostitch> also where has the bindings package go?
21:10 #navit: < aerostitch> :)
21:10 #navit: <+jkoan> Mainly everything is a plugin on the Navit perspective, even gui and graphics. Navit is extremely modular so I don't get the question
21:10 #navit: <+ilovekiruna> hi jkoan
21:10 #navit: <+ilovekiruna> sure
21:11 #navit: <+ilovekiruna> give me a minute
21:11 #navit: <+ilovekiruna> #417?
21:12 #navit: <+jkoan> Bindings are gone into the corresponding package binding python into python
21:12 #navit: <+jkoan> ilovekiruna: yes
21:12 #navit: < aerostitch> right, sorry I'm blind :)
21:14 #navit: < aerostitch> yeah I know about the plugins, but in the end-user point of view you will have the packages that are flavored by the environment they have running (gtk, opengl, etc)
21:14 #navit: <+ilovekiruna> jkoan: approved
21:15 #navit: <+jkoan> ilovekiruna: thx
21:15 #navit: < aerostitch> and the blocks they want to add like the fonts, the other plugins
21:15 #navit: < aerostitch> that's why I was thinking of separating the former from the later
21:16 #navit: < aerostitch> by having a prefix navit-{font,plugin,binding} in front of them
21:16 #navit: < aerostitch> I know I'm being pedantic here, just throwing the idea out
21:17 #navit: <+jkoan> ilovekiruna: even if its not need anymore I wanted to let you look over it so be sure it's not totally garbage
21:18 #navit: <+jkoan> aerostitch: I don't even know. I haven thought about it long enough (also it's really first time I separate a project into pieces)
21:19 #navit: <+jkoan> I would like to have a everything perfectly separated, but I even don't know the solution for this.
21:20 #navit: <+jkoan> But because navit is so much modular and mainly everything is a plugin we can separate it like we want
21:20 #navit: < aerostitch> well let me ask you this: if you were a end user that don't know shit about the software and wants a running navit for opengl, what would you do?
21:22 #navit: < aerostitch> then as an end user I want to load one of my garmin maps. I don't have the garmin plugin installed but I don't know that it exists, just want to load the map, what would happen? I'll need a message telling me what to install
21:22 #navit: <+jkoan> If I am a beginner user "apt install navit" and hope that apt manages to detect what the best for my system would be, if I am a advanced user probably install nsvit-opengl
21:22 #navit: < aerostitch> exactly
21:23 #navit: < aerostitch> but I can't have a message like this for all the actions I'm going to do, so we need to have a basic amount of plugin in the core package
21:23 #navit: < aerostitch> that would not make you want to look elsewhere as a beginner or intermediate user
21:24 #navit: < aerostitch> Do we have statistics on the usage of each of our plugins?
21:24 #navit: <+jkoan> So we would need the virtual navit package with a grep all and install everything and a navit-core with really the basics (run navit with null plugins)?
21:24 #navit: <+jkoan> Statistics would be really nice
21:25 #navit: < aerostitch> That would be really a huge help in the future to know which plugins are really used and separate out the plugins that are barely used
21:25 #navit: <+jkoan> If we want Statistics we need to separate them, right?
21:25 #navit: < aerostitch> lol
21:25 #navit: < aerostitch> not really
21:25 #navit: < aerostitch> with the work you're doing we'd be already able to see the stats reported by popcon in debian for example
21:26 #navit: < aerostitch> and a similar system could be in place in navit's core
21:26 #navit: < aerostitch> asking if you're ok to report plugins usage statistics when you install it
21:26 #navit: < aerostitch> https://qa.debian.org/popcon.php?package=navit
21:27 #navit: < aerostitch> but I digress
21:28 #navit: <+jkoan> <400 users don't seems to be much :(
21:29 #navit: < aerostitch> well that's the users installing it on a debian and agreeing to report their usage statistics
21:29 #navit: < aerostitch> I don't think it includes raspbian
21:30 #navit: <+jkoan> Yeah okay, navit isn't really used on desktop PCs, agreed :D
21:30 #navit: < aerostitch> and it surely don't include the other derivatives
21:30 #navit: < aerostitch> :)
21:30 #navit: <+jkoan> So what would you suggest finally for our new packages structure?
21:30 #navit: < aerostitch> so for the answer: yes but that's not exactly what I was asking. What I was pointing out is to try to keep it simple by placing ourselves in the end user's shoes.
21:31 #navit: < aerostitch> Well I think we're good right now
21:31 #navit: < aerostitch> just wondering about the naming convention we should take
21:32 #navit: < aerostitch> just wondering that to make clear about the differences between the packages specific to a graphics system and the plugins/fonts
21:37 #navit: <+jkoan> So that a "dumb" user don't install something manually which is requested by the virtual package?
21:38 #navit: <+jkoan> What about libnavit-gui-gtk, libnavit-grafics-gtk and navit-gtk as a virtual package containing both? Or something like this
21:39 #navit: <+jkoan> So navit-gtk would be all gtk things and core+data so a runnable navit?
21:40 #navit: < aerostitch> sounds good but would  libnavit-grafics-gtk & libnavit-gui-gtk be usable alone?
21:41 #navit: <+jkoan> No, if would also require navit core and data
21:41 #navit: <+jkoan> Which would be bundled by navit-gtk as a virtual package
21:43 #navit: <+jkoan> So the hierarchy would be navit (virt) = navit-gtk (viert) | navit-qt (girt) |...
21:44 #navit: <+jkoan> Navit-gtk (virt) = navit-core + navit-data + libnavit-*-gtk
21:44 #navit: <+jkoan> But without plugins
21:45 #navit: <+jkoan> Does this makes sense?
21:59 #navit: < aerostitch> it does
22:04 #navit: <+jkoan> Is it a good idea to have libnavit or isn't it intended like this?
22:06 #navit: < aerostitch> lib* are generally for libraries reusable by other softs used for exposing headers files but that's fine.
22:06 #navit: < aerostitch> Personally I would have just kept navit-gtk to be a real package that depends on navit-core and has graphics and gui
22:07 #navit: < aerostitch> but libnavit* works too
22:12 #navit: <+jkoan> Okay, then I will drop the idea of libnavit and put everything in the packages. I will think about every file again. But not now, now is sleep time. See you tomorrow
22:13 #navit: < aerostitch> Thanks! Have a good night
22:13 #navit: < aerostitch> and great job on the rework by the way
22:24 -!- j_f-f [~quassel@rs-7.jff-webhosting.net] has quit [Ping timeout: 268 seconds]
22:34 -!- j_f-f [~quassel@rs-7.jff-webhosting.net] has joined #navit
23:09 -!- Horwitz [~mich1@p200300800E7C2500022268FFFE64E7C4.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds]
23:17 -!- xenos1984 [~xenos1984@22-164-191-90.dyn.estpak.ee] has quit [Quit: Leaving.]
23:22 -!- Horwitz [~mich1@p200300800E796C00022268FFFE64E7C4.dip0.t-ipconnect.de] has joined #navit
23:22 -!- mode/#navit [+o Horwitz] by ChanServ
--- Log closed Thu Mar 29 00:00:02 2018