Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
Udo Richter wrote: 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 there is really a need for that special unsupported plugin, then the best way to go would be that at least one of all those distributions, who currently maintains that plugin, republishes it somewhere (AFAIR projects.vdr-developer.org was invented for that?). First step could be to apply all those patches that are required to get the plugin to work with current VDR *developer* versions. If a plugin really is still needed by a bigger group of people, then it definitively needs to be maintained at some *central* place. It doesn't help if every distribution creates their own patches. It's much better to cooperate! Yours Manuel ___ 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
If there is really a need for that special unsupported plugin, then the best way to go would be that at least one of all those distributions, who currently maintains that plugin, republishes it somewhere (AFAIR projects.vdr-developer.org was invented for that?). First step could be to apply all those patches that are required to get the plugin to work with current VDR *developer* versions. If a plugin really is still needed by a bigger group of people, then it definitively needs to be maintained at some *central* place. It doesn't help if every distribution creates their own patches. It's much better to cooperate! We are talking about 100 Plugins. Maybe we can drop the half of these but 50 will be remaining ... -- Helmut Auer, hel...@helmutauer.de ___ 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
Klaus Schmidinger wrote: 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... The changes in 1.7.34 are a big change into the right direction! In context of a plugin, VDR should be something like a backend library. It has to be installed, but the plugin should be compilable from *everywhere* as long as the backend library is there. This is why pkg-config was invented and this is how all other software projects out there work. VDR, so far, had a *very* special Makefile system. Running make, even if VDR is installed, just failed and the lack of make install causes the need that plugin authors have to document how to *manually* complete the installation as the Makefile won't do it and can't do it. So nearly every plugin needs its own way to compile it from outside of a VDR source (that most distributions don't even install, as they only install the include-directory) and even more plugins need special handling to get it equipped with all those additional files, they need to operate (images, stillpictures, ...). With the new system, anything should work with two commands: make followed by make DESTDIR=... install Of course there is now some additional work to get *useful* usecases of the old Makefile system to work again. Klaus already started with a first patch and I'm sure we can resolve other issues, too. And about all those unsupported plugins: Do we really want to freeze all VDR interfaces just to keep those old, unsupported things working? If the original author lost interest, then there are only two options: Someone has to take it over or it should be dropped at all. 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... And with the next changes in the editing code, EPG code and $WHATEVER code the next one whines and you offer to freeze that part of code, again? So why not freeze VDR development at all? Or maybe, the people, that so much like the current status of VDR 1.7.33 (or maybe 1.7.31?) just roll their own fork and do whatever with it, so innovation in the core VDR project can go on? Just remember: Nobody likes change except a wet baby Yours Manuel ___ 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
OK. 50 plugins doesn't sound impossible to deal with. But they have to be in one place, as Manuel mentioned. Name these 50 unmaintained plugins and then we can check when and how they'll be moved to vdr-developer.org. Christopher 2012/12/29 Helmut Auer v...@helmutauer.de: If there is really a need for that special unsupported plugin, then the best way to go would be that at least one of all those distributions, who currently maintains that plugin, republishes it somewhere (AFAIR projects.vdr-developer.org was invented for that?). First step could be to apply all those patches that are required to get the plugin to work with current VDR *developer* versions. If a plugin really is still needed by a bigger group of people, then it definitively needs to be maintained at some *central* place. It doesn't help if every distribution creates their own patches. It's much better to cooperate! We are talking about 100 Plugins. Maybe we can drop the half of these but 50 will be remaining ... -- Helmut Auer, hel...@helmutauer.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ 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
Helmut Auer wrote: We are talking about 100 Plugins. Maybe we can drop the half of these but 50 will be remaining ... No problem. Let's start a discussion about this in a separate thread. I bet that about 20 more plugins aren't worth the effort and so about 30 plugins will be left. Porting them to projects.vdr-developer.org shouldn't be that difficult. Yours Manuel ___ 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 12/29/2012 01:14 PM, Helmut Auer wrote: If there is really a need for that special unsupported plugin, then the best way to go would be that at least one of all those distributions, who currently maintains that plugin, republishes it somewhere (AFAIR projects.vdr-developer.org was invented for that?). First step could be to apply all those patches that are required to get the plugin to work with current VDR *developer* versions. If a plugin really is still needed by a bigger group of people, then it definitively needs to be maintained at some *central* place. It doesn't help if every distribution creates their own patches. It's much better to cooperate! We are talking about 100 Plugins. Maybe we can drop the half of these but 50 will be remaining ... Nevertheless, hosting them on vdr-developer.org seems to be the best solution. If of those remaining, let's say, just the most wanted 10 to 30% of the plugins would find some adoptive parents we would have a win situation. Those maintainers do not have to commit themselves alone to keep the pace with vdr developer versions, rather several skilled users even, who are able to contribute patches now and then and also are interested in the specific plugins may jointly try to maintain the plugins they are interested in and would be otherwise orphaned, in that central place. Of course, distribution maintainers can join them too, but really, the central place is really important here, and the fact that such a plugin may be adapted to new API changes not just by one single person who might not be available for that at some point. ___ 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 12/29/2012 01:07 PM, Manuel Reimer wrote: [..] In context of a plugin, VDR should be something like a backend library. It has to be installed, but the plugin should be compilable from *everywhere* as long as the backend library is there. This is why pkg-config was invented and this is how all other software projects out there work. VDR, so far, had a *very* special Makefile system. Running make, even if VDR is installed, just failed and the lack of make install causes the need that plugin authors have to document how to *manually* complete the installation as the Makefile won't do it and can't do it. So nearly every plugin needs its own way to compile it from outside of a VDR source (that most distributions don't even install, as they only install the include-directory) and even more plugins need special handling to get it equipped with all those additional files, they need to operate (images, stillpictures, ...). With the new system, anything should work with two commands: make followed by make DESTDIR=... install This is actually more or less the scenario vdr and all of its plugins have always been *installed* on Gentoo, which in a certain way shifts the actual execution of the actions the package maintainer defined, to the user's machine, by compiling from a plugin source directory (sort of transparently, when the user actually installs with the help of the package manager). Maintainers only had a great deal of work to override what the native VDR build system did (or in most cases, simply omitted to do) mainly on installation. So yes, being able to just issue the commands mentioned above by Manuel, would simplify things a lot... [..] So why not freeze VDR development at all? Or maybe, the people, that so much like the current status of VDR 1.7.33 (or maybe 1.7.31?) just roll their own fork and do whatever with it, so innovation in the core VDR project can go on? Just remember: Nobody likes change except a wet baby So, +1 from me, to switch to the new system, which should make everyone happy, those building like Klaus everything from one big source tree and not even installing, and those wanting to be able to build from the plugin source only. Since you mentioned the wet baby, c'mon folks, let's cut this baby shit whining and just get over it, let Klaus do the change, isn't it wonderful enough he's willing to listen to opinions? Just my 2 cents, Lucian ___ 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
von Manuel Reimer manuel.rei...@gmx.de The changes in 1.7.34 are a big change into the right direction! FullAck, but really at that time of 1.7.xx? At this time where 1.7.xx is more less saddled by all HDTV users? Many new festures have been postponed after V2 release. Some of them wouldn't have this significant impact to the VDR univers, like these changes on the Makefile structure. Wouldn't it possible to focus release of V2 and set these changes as very first change on the upcoming developer release. === 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 29.12.2012 17:52, fnu wrote: von Manuel Reimer manuel.rei...@gmx.de The changes in 1.7.34 are a big change into the right direction! FullAck, but really at that time of 1.7.xx? At this time where 1.7.xx is more less saddled by all HDTV users? Many new festures have been postponed after V2 release. Some of them wouldn't have this significant impact to the VDR univers, like these changes on the Makefile structure. Wouldn't it possible to focus release of V2 and set these changes as very first change on the upcoming developer release. From what I have seen in this thread lately, I don't think the outcry would have been any less then... 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
von Klaus Schmidinger klaus.schmidin...@tvdr.de From what I have seen in this thread lately, I don't think the outcry would have been any less then... You're maybe right, but I'm not sure. Because now, everybody does know, these changes will happen soon, no Plugin for V2.1 w/o rework. But V2.1 is near future, so time for rework, V1.7.xx is present, right now, looking for continuity. Kick a sibling of 1.7.33 out as V2 or maybe an in between stable release called V1.8 and go ahead with these important changes in V1.9 ... just a thought ... === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Standardized DVB signal info up for review!
As many know, getting standardized dvb signal info in linux has been a want for a very long time for a lot of users (and developers). There has been several talks/threads about it but nothing was ever merged. The subject has come up once again and Mauro has posted a patch for review. I know that there are at least a handful of coders here who have interest in this, including Klaus. I strongly urge anyone who would like to see this finally happen to take a few minutes and read the links below. Further, it would be great if people actively participated in the discussion so please post anything you may like to contribute to the discussion! The patch and discussion is available at: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters http://www.mail-archive.com/linux-media@vger.kernel.org/msg56557.html ___ 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? Beside all the current whining (and *I* don't exclude myself from that), it is nevertheless a step in the right direction. Just returning to the old system wouldn't solve any of the basic problems that this change addressed. Things that could have been handled better: - More discussion about the best strategy beforehand. Even if there was an thread in vdr-portal, I did miss it, and there was no word of it in the mailing list, which I always considered to be the central spot of development. Right now it leaves the impression that the new system was designed to make exactly two persons satisfied for their needs. - Some smooth transition strategy. At least for some versions being able to use the old and new makefile system would help a lot. That was actually the next trick I wanted to check, whether there's a safe way to grep for old vs. new system and handle them differently: Old system would just make all, and instead of make install copy from the old folders, while new system passes make all and make install to the plugin. Another improvement would be a way to explicitly tell the plugin that its being build in the source tree, and that ../../lib etc. should be a target, but that needs to be supported by all the plugins. - Some compatibility strategy. Being able to build the same plugin source under several VDR versions helps plugin developers a lot. Though this is not VDR's concern, it helps to keep that in mind. So all in all, lets just look forward, not backward, and find ways to improve the system. 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
2012/12/29 Udo Richter udo_rich...@gmx.de: Even if there was an thread in vdr-portal, I did miss it, and there was no word of it in the mailing list, which I always considered to be the central spot of development. Really? http://linuxtv.org/pipermail/vdr/2012-November/026813.html There was NO answer at all. I don't consider the mailinglist as central spot of developement. Here I'm forced to speak English. Almost all VDR Users are German. And in VDR-Portal I reach the critical mass. With the addition that I am allowed to speak my native language. Right now it leaves the impression that the new system was designed to make exactly two persons satisfied for their needs. Yes, I am happy with the new makefiles. I (and I think Klaus, too) knew that this change is not perfect, and that it would need further improvement. We are all willing to fix the remaining problems. Christopher ___ 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
OK. 50 plugins doesn't sound impossible to deal with. But they have to be in one place, as Manuel mentioned. Name these 50 unmaintained plugins and then we can check when and how they'll be moved to vdr-developer.org. there is a small list, ~30 plugins on https://bugs.gentoo.org/show_bug.cgi?id=414177 and his depended bugs. they fails early on the obsolet i18n handling beware, this list is not complet, iam fixed a lot of plugins in the background, most on user pressure ;) Anyway, i think the plugins will kicked if vdr-2.0 goes in the maintree, while there is no feedback/request from the users -- Regards Gentoo Developer Joerg Bornkessel hd_bru...@gentoo.org ___ 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
von Christopher Reimer c.reimer1...@gmail.com Yes, I am happy with the new makefiles. I'm glad to hear this, but what about all the other developers and users? Developer version back and forth, VDR 1.7.xx has become silently a somewhat stable version over the years, due to it's HDTV capability. Becoming an official stable is honestly long overdue. Nobody can really argue anymore, 1.7 is a developer version, because no HDTV user, not even Klaus, can go back to stable SDTV VDR 1.6, whereas the majority doesn't have any hardware for that anymore ... A massive excluding change like this, is something for a new developer branch and not a thing for a development cycle where the end could already be smelled ... And as far as I remember nobody did complain about the old Makefile structur, and yes I mean nobody, because the two now known just changed it w/o warning. Do what ever you need to do, I appriciate it, but remind always some continuity for all others in the VDR universe. The situation right now does need a solution, but it can't be the words of Walter Ulbricht: Vorwärts immer, rückwärts nimmer ... A compromise must be possible, whatever it looks like, otherwise my comparison with Louis XIV hasn't been wrong ... === 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 Saturday 29 December 2012 - 18:39:05, fnu wrote: .. or maybe an in between stable release called V1.8 and go ahead with these important changes in V1.9 ... just a thought ... +1 Gero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
