Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
On 28.12.2012 00:43, Helmut Auer wrote: If I don't accept patches, I'm blamed for slowing down development. If I do accept a patch that causes a little work to adapt to (but looks promising in the long run), I'm being offended by being compared to Louis XIV. I guess you just can't win 'em all... You're absolutely right here. The problem behind is that there are about 250 working plugins for VDR and about 200 of these are only maintained by the distributors. Well, if a plugin is no longer actively maintained, it's probably time to drop it. You know what they say about dead horses ;-). So its a lot of work for all distributors to patch these plugins to get those running again. (And I would prefer for my distri to patch VDR instead of fixing these plugin Makefiles) But you don't have to care about this, the distributors are using many patches :) If you put all your plugins into PLUGINS/src under the VDR source directory (with the old Make.global still in place), change into PLUGINS/src and do for i in *; do make -C $i all; done I would guess that they build regardless whether they use an old or new Makefile. Maybe you should give it a try. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
On 28.12.2012 00:47, Dominic Evans wrote: On 27 Dec 2012, at 23:41, fnu v...@auktion.hostingkunde.de mailto:v...@auktion.hostingkunde.de wrote: Linux wouldn't have been that succesfull, if Linus Torvalds would not had an ear to the needs of others, even business needs ... A Christmas message from Linus – “IF YOU BREAK USERSPACE I HATE YOU AND YOU ARE A TERRIBLE PERSON” http://article.gmane.org/gmane.linux.kernel/1414106 Well, Linus apparently has very strong feelings about this. However, nowhere in that posting does it say IF YOU BREAK USERSPACE I HATE YOU AND YOU ARE A TERRIBLE PERSON So did *you* (Dominic) just make that up? I'm asking because your posting looks just like a direct quotation from Linus, and I have a hard time imagining a renowned person like Linus Torvalds to say something like that. Not breaking userspace is, of course, the right thing to do in a *stable* version of any software. But if this means that you can't do anything new in a *developer* version, then I guess this means we should rather stop doing any further development and just sit on what we have. But that would cause people complaining about a lack of innovation, I guess... Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
On Friday 28 December 2012 - 09:29:01, Klaus Schmidinger wrote: Well, Linus apparently has very strong feelings about this. However, nowhere in that posting does it say IF YOU BREAK USERSPACE I HATE YOU AND YOU ARE A TERRIBLE PERSON I guess, most of confusion and frictions comes from the fact, that you use c++ as programming language, but you don't code c++ and you don't think as a c++- developer. Same - you developed a linux app, but you don't care about linux standards. Your behaviour is like a windows coder, that is forced to work on a linux box. There are lots of issues, raised from *you* being bullheaded and ignorant to community and their standards. *That's your right* - as vdr is your baby and I support your right of being the way you like to be. ... but I don't support you being astonished and mock about people that like and follow standards. kind regards Gero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
On 28 December 2012 09:29, Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: IF YOU BREAK USERSPACE I HATE YOU AND YOU ARE A TERRIBLE PERSON So did *you* (Dominic) just make that up? I'm asking because your posting looks just like a direct quotation from Linus, and I have a hard time imagining a renowned person like Linus Torvalds to say something like that. Apologies, I shouldn't have put double quotes; it wasn't actually meant to look like a quote, but to be a summary of the general gist of the posting. I was just trying to refute the suggestion that Linus was a perfect example of friendlyness :) Not breaking userspace is, of course, the right thing to do in a *stable* version of any software. But if this means that you can't do anything new in a *developer* version, then I guess this means we should rather stop doing any further development and just sit on what we have. But that would cause people complaining about a lack of innovation, I guess... Personally I think you (Klaus) should be free to experiment and do whatever you like with the developer snapshots that you put on the mailing list. There is no requirement for plugin authors and distributions to keep up-to-date with every single release, and end users shouldn't expect that. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
On 28 December 2012 10:07, Gero geronimo...@gmx.de wrote: I guess, most of confusion and frictions comes from the fact, that you use c++ as programming language, but you don't code c++ and you don't think as a c++- developer. Same - you developed a linux app, but you don't care about linux standards. *SNIP* ... but I don't support you being astonished and mock about people that like and follow standards. Rubbish. Afaik Klaus has only ever mocked the fact the the standards differ so much between all the different distributions; not the idea of them itself. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
Am 28.12.2012 09:28, schrieb Klaus Schmidinger: Well, if a plugin is no longer actively maintained, it's probably time to drop it. You know what they say about dead horses ;-). Being actively developed and being needed are two different things. I wouldn't want to drop all the plugins that aren't under active development any more, as this would probably be true for 2/3 of my plugins. If you put all your plugins into PLUGINS/src under the VDR source directory (with the old Make.global still in place), change into PLUGINS/src and do for i in *; do make -C $i all; done I would guess that they build regardless whether they use an old or new Makefile. Maybe you should give it a try. Nope, as you forgot to filter out folders with version numbers. Plus, any updated plugin (at least any built-in plugin) does no longer create the *.so.$APIVERSION file, and there's no generic way to do this. All updated plugins require an additional make install, that will create the *.so.$APIVERSION in some folder defined in vdr.pc. However, some old-style plugins will do totally different things on make install, like xineliboutput for example. Thats why I wasn't even able to set up a running test build of my VDR yet, even though it complied without any issues: Total mess of .so files. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
On 28.12.2012 14:19, Udo Richter wrote: Am 28.12.2012 09:28, schrieb Klaus Schmidinger: Well, if a plugin is no longer actively maintained, it's probably time to drop it. You know what they say about dead horses ;-). Being actively developed and being needed are two different things. I wouldn't want to drop all the plugins that aren't under active development any more, as this would probably be true for 2/3 of my plugins. If you put all your plugins into PLUGINS/src under the VDR source directory (with the old Make.global still in place), change into PLUGINS/src and do for i in *; do make -C $i all; done I would guess that they build regardless whether they use an old or new Makefile. Maybe you should give it a try. Nope, as you forgot to filter out folders with version numbers. Well, it's a makeshift solution, so you could just make sure there are only folders you want to be handled. Plus, any updated plugin (at least any built-in plugin) does no longer create the *.so.$APIVERSION file, and there's no generic way to do this. Well, then maybe this works (haven't tested it): for i in *; do make -C $i all; cp $i/libvdr-$i.so ../../PLUGINS/lib/libvdr-$i.so.1.7.34; done All updated plugins require an additional make install, that will create the *.so.$APIVERSION in some folder defined in vdr.pc. However, some old-style plugins will do totally different things on make install, like xineliboutput for example. Thats why I wasn't even able to set up a running test build of my VDR yet, even though it complied without any issues: Total mess of .so files. The question is whether you really *want* to get things running ;-) It's totally up to you what you do. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
Am 28.12.2012 14:37, schrieb Klaus Schmidinger: On 28.12.2012 14:19, Udo Richter wrote: Plus, any updated plugin (at least any built-in plugin) does no longer create the *.so.$APIVERSION file, and there's no generic way to do this. Well, then maybe this works (haven't tested it): for i in *; do make -C $i all; cp $i/libvdr-$i.so ../../PLUGINS/lib/libvdr-$i.so.1.7.34; done As I said, no generic way to do this. For example: epgsearch/libvdr-conflictcheckonly.so epgsearch/libvdr-quickepgsearch.so epgsearch/libvdr-epgsearchonly.so epgsearch/libvdr-epgsearch.so streamdev/client/libvdr-streamdev-client.so streamdev/server/libvdr-streamdev-server.so servicedemo/libvdr-svccli.so servicedemo/libvdr-svcsvr.so xineliboutput/libxineliboutput-fbfe.so.1.0.90-cvs xineliboutput/libvdr-xineliboutput.so.1.7.34 xineliboutput/libxineliboutput-sxfe.so.1.0.90-cvs Different locations, different file names, sometimes multiple files, sometimes other .so files that are not needed. Until now, make all did that magic, and lots of plugins did it their way. Now there is no way to get all needed files except running make install. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
I don't think arguing which userspace is bigger is so important. I'm rather silent user and use VDR a few years now. First I compiled it from scratch because there were no other option. Then I tried to use packages but failed. Packages were outdated, only a few plugins in repository. No good decription how to compile those missing myself. Next I used eTobi packages (fits Debian distro), yaVDR packages (Ubuntu based but usable on Debian). Now I use packages from Debian, compiling myself a few missing plugins and installing them manually. I agree that make;make install is behind most of us, linux users. And I like this change. Hovewer I wouldn't bash those who still use it, it's linux freedom. Personally I don't like digging /var/lib/vdr, /etc/default/vdr etc so I did symlinks to have all in one place, as it is in source installation. Hovewer I like running apt, U, g and after a while new VDR version is running with (almost) all plugins working. And I think it's the way to go. Geek can clone repositories, patch and compile VDR and plugins himself. It's the man who will dig mailing list, who will ask question. But casual user who needs only working application need stable working packages. He will not come here because he don't know what mailing list is. He probably doesn't know irc and will not create news account nor login to vdr portal (mainly in german language anyway). I also disagree with pointing at 1.6 as a stable release. Let's look at ftp://ftp.tvdr.de/vdr/ vdr-1.6.0.tar.bz2 Mar 23 2008 Do you really suuggest to use software released more then 4 years old? I understand that sometimes software isn't actively developed and so there is no developers to work on releases. Hovewer 1.7 is actively developed and has so many important changes that 1.6 is no longer usable. I'm not criticizing lack of new stable release, it's Klaus choice. Hovewer you shoudln't criticize people who try to use developer version - they have no option to use stable one because there is no such version which can be used (1.6 doesn't work with HD, right?). Marx ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
On 28.12.2012 14:42, Udo Richter wrote: Am 28.12.2012 09:29, schrieb Klaus Schmidinger: On 28.12.2012 00:47, Dominic Evans wrote: IF YOU BREAK USERSPACE I HATE YOU AND YOU ARE A TERRIBLE PERSON Not breaking userspace is, of course, the right thing to do in a *stable* version of any software. In Linux context, it actually means keep compatibility to any userspace app across as many generations of stable releases as possible. It means for example, that any program written and compiled against the DVBv3 API still works, and will work for several years on, even though DVBv5 is so much better. For plugin developers it means, don't demand that the user has to use a certain VDR version. If plugin foo only works with VDR-1.7.xy, and plugin bar requires VDR-1.7.ab, the user looses. Good plugins should work with any version at least back to the last stable release. And the recent changes didn't make things easier. Right now I'm in the awkward situation that I cannot port my plugins to .34 because for serious tests I need ported versions of several other plugins. Its a chicken-and-egg thing, and right now all the eggs are broken. So should we go back to the Makefiles of version 1.7.33 and declare this area of the program source untouchable forever? Maybe this would be the easiest solution, and I wouldn't get bashed, offended and insulted that much any more. Never in my wildest dreams would I have expected such an outrage about this change, which was entirely intended to make things simpler in the future. But if this is not what people want, then let's just stick with the old Makefiles and declare version 1.7.34 a complete and utter failure... Beware - I'm not kidding about this! If this whining keeps going on, I will switch back to version 1.7.33 Makefiles, and I won't dare touch them again any time soon! After all, I didn't make this change because *I* wanted it... Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
On 28.12.2012 16:38, Klaus Schmidinger wrote: On 28.12.2012 14:42, Udo Richter wrote: Am 28.12.2012 09:29, schrieb Klaus Schmidinger: On 28.12.2012 00:47, Dominic Evans wrote: IF YOU BREAK USERSPACE I HATE YOU AND YOU ARE A TERRIBLE PERSON Not breaking userspace is, of course, the right thing to do in a *stable* version of any software. In Linux context, it actually means keep compatibility to any userspace app across as many generations of stable releases as possible. It means for example, that any program written and compiled against the DVBv3 API still works, and will work for several years on, even though DVBv5 is so much better. For plugin developers it means, don't demand that the user has to use a certain VDR version. If plugin foo only works with VDR-1.7.xy, and plugin bar requires VDR-1.7.ab, the user looses. Good plugins should work with any version at least back to the last stable release. And the recent changes didn't make things easier. Right now I'm in the awkward situation that I cannot port my plugins to .34 because for serious tests I need ported versions of several other plugins. Its a chicken-and-egg thing, and right now all the eggs are broken. So should we go back to the Makefiles of version 1.7.33 and declare this area of the program source untouchable forever? Maybe this would be the easiest solution, and I wouldn't get bashed, offended and insulted that much any more. Never in my wildest dreams would I have expected such an outrage about this change, which was entirely intended to make things simpler in the future. But if this is not what people want, then let's just stick with the old Makefiles and declare version 1.7.34 a complete and utter failure... Beware - I'm not kidding about this! If this whining keeps going on, I will switch back to version 1.7.33 Makefiles, and I won't dare touch them again any time soon! After all, I didn't make this change because *I* wanted it... Klaus P.S.: Udo, the whining part was, of course, not personally addressed to you. Just wanted to clarify that ;-) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
Am 28.12.2012 16:38, schrieb Klaus Schmidinger: So should we go back to the Makefiles of version 1.7.33 and declare this area of the program source untouchable forever? +1 Gerald !DSPAM:50ddc50a174441059718148! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
Am 28.12.2012 16:38, schrieb Klaus Schmidinger: So should we go back to the Makefiles of version 1.7.33 and declare this area of the program source untouchable forever? Maybe this would be the easiest solution, and I wouldn't get bashed, offended and insulted that much any more. Never in my wildest dreams would I have expected such an outrage about this change, which was entirely intended to make things simpler in the future. But if this is not what people want, then let's just stick with the old Makefiles and declare version 1.7.34 a complete and utter failure... Beware - I'm not kidding about this! If this whining keeps going on, I will switch back to version 1.7.33 Makefiles, and I won't dare touch them again any time soon! After all, I didn't make this change because *I* wanted it... Building plugins outside the vdr source tree with the new Makefile is something I bear with the current mess. I'm no Makefile-guru, so I have to live with it and I can't contribute to this thing at all. My personal development environment is a vdr source tree with plugins. If I do development on a vdr-patch, I just call make and have the output (and errors/warnings) of the compiler right there. If I work on a plugin I have a separate shell in the plugin's directory where I call make. If it's ready for testing, I call make all plugins from the vdr directory. In the directory above (..) I have a script which starts the current vdr with the settings for my development (other config directory etc.). Now a make compiles everything and I have to scroll a lot to get the warnings or errors. Perhaps we should talk about what targets are needed and what they should do. Never touch a running system only applies to productive environments, not for development. Without touching there would be no progress. So please stop whining and let's do some work together! Lars. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
Let's not waste more mailing list space with this nonsense. I got it already, you're way of installation and usage of VDR is the only valid, all others are stupid. Your statements here are the one and only truth, even so only you are allowed to make conclusions. Yes man, you're the very last knight keeping the holy grail of VDR. === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
On Fri, Dec 28, 2012 at 11:19 AM, fnu v...@auktion.hostingkunde.de wrote: Let's not waste more mailing list space with this nonsense. I got it already, you're way of installation and usage of VDR is the only valid, all others are stupid. Your statements here are the one and only truth, even so only you are allowed to make conclusions. Yes man, you're the very last knight keeping the holy grail of VDR. Please stop trolling this mailing list with your absurd nonsense garbage. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] road-map
On Fri, Dec 28, 2012 at 1:58 PM, Peter Münster pmli...@free.fr wrote: Hi, Is there some kind of road-map for VDR? Things like: - What is expected to happen before next stable release? - Approximate time-line. - What features are to be integrated? Yes but it's kept in a vault under 24hr armed guard. Fortunately every now then Klaus accidentally slips and leaks a bit of info here there but you'd have better luck getting your hands secret alient technology than on that TODO list. ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
