Hi,
as mentioned in the VDR-1.7.34 announcement, Make.config is now gone for plugins.
Make.config gave me the opportunity to control features or behavior of plugins and VDR at a central location without having the need to adjust each plugin's Makefile. For example, while developing vdr-xine, I could keep vdr-xine's Makefile in a distributable state and still control to enable some features I'd like to use in my local configuration. And when upgrading some other plugins at bugfix level (i. e. there are usually no new features and hence the config variables can stay the same), there was no need to adjust the Makefile due to the config entries in Make.config.
Here is an excerpt of my Make.config for an example of the above mentioned configuration settings:
#xine #VDR_XINE_VDR_HAS_TRUECOLOR_OSD = 1 VDR_XINE_SET_VIDEO_WINDOW = 1 VDR_XINE_VERIFY_BITMAP_DIRTY = 0
#burn DVDDEV=/dev/hdd ISODIR=/video
#vdr BIDI=1 VFAT=1 REMOTE=LIRC LIRC_PUSHFREQ=64 # 1/s LIRC_REPEATDELAY=250 # ms LIRC_REPEATFREQ=32 # 1/s #LIRC_REPEATTIMEOUT=500 # ms #LIRC_RECONNECTDELAY=3000 # ms LIRC_PRIORITYBOOST=1
#muggle HAVE_ONLY_SERVER=1
As you can see, there is nothing like changing compiler or linker settings -- for that stuff, I really appreciate the way it is done now.
In a private discussion with kls, he asked me to talk to other plugin developers too (so here we are) about that issue, so that any solution in that regard will be of broad agreement by all developers.
To conclude: 1.) there is a need for a common make configuration file for both VDR and plugins.
2.) the file should be included in VDR's Makefile after including Make.config (maybe that idea should be dropped in favor of 5.a) as any VDR related option can be put into Make.config anyway).
3.) the file should be included into plugin Makefiles after having set PLUGIN and VERSION to be able to have some plugin-/version-dependent configuration.
4.) the file is optional -- maybe a template file like Make.config.template could indicate that there is something available for tuning.
5.) how do we name the file? 5.a) plugins.conf (doesn't fit perfectly for 2., to be a common file for VDR too) 5.b) Make.common 5.c) local.conf 5.d) Make.config.local
6.) where do we put the file? 6.a) kls suggested /etc/vdr at a random shot 6.b) I would like to put it next to Make.config 6.c) use pkg-config to determine path (defaults to VDRDIR)
Please start sharing your ideas now ;-)
Bye.
On 25.12.2012 20:47, Reinhard Nissl wrote:
Hi,
as mentioned in the VDR-1.7.34 announcement, Make.config is now gone for plugins.
Make.config gave me the opportunity to control features or behavior of plugins and VDR at a central location without having the need to adjust each plugin's Makefile. For example, while developing vdr-xine, I could keep vdr-xine's Makefile in a distributable state and still control to enable some features I'd like to use in my local configuration. And when upgrading some other plugins at bugfix level (i. e. there are usually no new features and hence the config variables can stay the same), there was no need to adjust the Makefile due to the config entries in Make.config.
Here is an excerpt of my Make.config for an example of the above mentioned configuration settings:
#xine #VDR_XINE_VDR_HAS_TRUECOLOR_OSD = 1 VDR_XINE_SET_VIDEO_WINDOW = 1 VDR_XINE_VERIFY_BITMAP_DIRTY = 0
#burn DVDDEV=/dev/hdd ISODIR=/video
#vdr BIDI=1 VFAT=1 REMOTE=LIRC LIRC_PUSHFREQ=64 # 1/s LIRC_REPEATDELAY=250 # ms LIRC_REPEATFREQ=32 # 1/s #LIRC_REPEATTIMEOUT=500 # ms #LIRC_RECONNECTDELAY=3000 # ms LIRC_PRIORITYBOOST=1
#muggle HAVE_ONLY_SERVER=1
As you can see, there is nothing like changing compiler or linker settings -- for that stuff, I really appreciate the way it is done now.
In a private discussion with kls, he asked me to talk to other plugin developers too (so here we are) about that issue, so that any solution in that regard will be of broad agreement by all developers.
To conclude: 1.) there is a need for a common make configuration file for both VDR and plugins.
No, only for *plugins*! VDR itself will have nothing to do with this file!
2.) the file should be included in VDR's Makefile after including Make.config (maybe that idea should be dropped in favor of 5.a) as any VDR related option can be put into Make.config anyway).
See 1.).
3.) the file should be included into plugin Makefiles after having set PLUGIN and VERSION to be able to have some plugin-/version-dependent configuration.
Agreed.
4.) the file is optional -- maybe a template file like Make.config.template could indicate that there is something available for tuning.
5.) how do we name the file? 5.a) plugins.conf (doesn't fit perfectly for 2., to be a common file for VDR too)
No need, see 1.).
5.b) Make.common 5.c) local.conf 5.d) Make.config.local
6.) where do we put the file? 6.a) kls suggested /etc/vdr at a random shot 6.b) I would like to put it next to Make.config 6.c) use pkg-config to determine path (defaults to VDRDIR)
Can't we just agree on a fixed place for this file? Does it really have to be somewhere else on every system?
I suggest to put the lines
PLGCFG ?= /etc/vdr/plugins.conf -include $(PLGCFG)
into each plugin's Makefile and that's it.
Klaus
2012/12/25 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
3.) the file should be included into plugin Makefiles after having set PLUGIN and VERSION to be able to have some plugin-/version-dependent configuration.
Agreed.
No. Not agreed.
Just use DEFINES+= in Make.config, and if that doesn't work, plugin makefiles have to be patched.
There's also the possibility to add a Make.config to every plugin. Some plugin maintainer already started to include their own Make.config (e.g. http://projects.vdr-developer.org/git/vdr-plugin-ripit.git/tree/Make.config....)
Christopher
Hi,
Am 26.12.2012 09:53, schrieb Christopher Reimer:
2012/12/25 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
3.) the file should be included into plugin Makefiles after having set PLUGIN and VERSION to be able to have some plugin-/version-dependent configuration.
Agreed.
No. Not agreed.
Just use DEFINES+= in Make.config, and if that doesn't work, plugin makefiles have to be patched.
I understand that this seems to be a quite simple solution, because in the end, almost any other configuration option will be converted to either compiler or linker settings. But it's quite lowlevel and one has to dig through the Makefile in depth to extract the necessary compiler or linker options.
And as you already mention, plugin Makefiles need to be patched to get it working. For example, there can nolonger be any default values in the Makefile that get always passed to the compiler as a define, as one cannot override it with a different value in Make.config. The default value has to go into the source file in case a certain define (and hence, a specific value) has not been passed to the compiler.
I think that we should keep the possibility to configure highlevel plugin options from a central place like plugins.conf just as Make.config did up to VDR-1.7.33.
There's also the possibility to add a Make.config to every plugin. Some plugin maintainer already started to include their own Make.config (e.g. http://projects.vdr-developer.org/git/vdr-plugin-ripit.git/tree/Make.config....)
Well, that's not what I was looking for, but kls suggested that already on vdr-portal too. I dislike on that solution that there is not a single central configuration file, but a symbolic link could do the trick to share a common file.
Bye.
Reinhard Nissl wrote:
I understand that this seems to be a quite simple solution, because in the end, almost any other configuration option will be converted to either compiler or linker settings. But it's quite lowlevel and one has to dig through the Makefile in depth to extract the necessary compiler or linker options.
... so we have the same situation, we always had. You either have to find the configuration options in the Makefile or you have to find them somewhere in the documentation of the plugin, you want to build.
I think that we should keep the possibility to configure highlevel plugin options from a central place like plugins.conf just as Make.config did up to VDR-1.7.33.
What is your plan? Do you want to build plugins "the old way" inside the VDR source dir? If so, then just add your options to your "Make.config" as you did in the past, but prefix them with an "export ". Something like:
export PLUGIN_OPTION = "any_value"
This way the options reach the plugin Makefiles if you do your "make plugins" as the global VDR Makefile exports the value.
If you don't plan to build all your plugins from the VDR source file, then a global configuration isn't needed. Then, the configuration should be part of the distribution specific package build scripts.
Yours
Manuel
Hi,
Am 26.12.2012 15:54, schrieb Manuel Reimer:
I think that we should keep the possibility to configure highlevel plugin options from a central place like plugins.conf just as Make.config did up to VDR-1.7.33.
What is your plan? Do you want to build plugins "the old way" inside the VDR source dir? If so, then just add your options to your "Make.config" as you did in the past, but prefix them with an "export ". Something like:
export PLUGIN_OPTION = "any_value"
This way the options reach the plugin Makefiles if you do your "make plugins" as the global VDR Makefile exports the value.
Thanks for this hint. This is what I was looking for. If it works as you write, then at least I have no need for plugins.conf at the moment.
Bye.
I prefer to keep files for a given program together in that programs tree. Not scatter all over the computer like ms. The only thing for vdr I move is the recordings because of the space required. All settings/config files for vdr belong in the vdr directory tree.
On 12/25/2012 1:07 PM, Klaus Schmidinger wrote:
On 25.12.2012 20:47, Reinhard Nissl wrote:
Hi,
as mentioned in the VDR-1.7.34 announcement, Make.config is now gone for plugins.
Make.config gave me the opportunity to control features or behavior of plugins and VDR at a central location without having the need to adjust each plugin's Makefile. For example, while developing vdr-xine, I could keep vdr-xine's Makefile in a distributable state and still control to enable some features I'd like to use in my local configuration. And when upgrading some other plugins at bugfix level (i. e. there are usually no new features and hence the config variables can stay the same), there was no need to adjust the Makefile due to the config entries in Make.config.
Here is an excerpt of my Make.config for an example of the above mentioned configuration settings:
#xine #VDR_XINE_VDR_HAS_TRUECOLOR_OSD = 1 VDR_XINE_SET_VIDEO_WINDOW = 1 VDR_XINE_VERIFY_BITMAP_DIRTY = 0
#burn DVDDEV=/dev/hdd ISODIR=/video
#vdr BIDI=1 VFAT=1 REMOTE=LIRC LIRC_PUSHFREQ=64 # 1/s LIRC_REPEATDELAY=250 # ms LIRC_REPEATFREQ=32 # 1/s #LIRC_REPEATTIMEOUT=500 # ms #LIRC_RECONNECTDELAY=3000 # ms LIRC_PRIORITYBOOST=1
#muggle HAVE_ONLY_SERVER=1
As you can see, there is nothing like changing compiler or linker settings -- for that stuff, I really appreciate the way it is done now.
In a private discussion with kls, he asked me to talk to other plugin developers too (so here we are) about that issue, so that any solution in that regard will be of broad agreement by all developers.
To conclude: 1.) there is a need for a common make configuration file for both VDR and plugins.
No, only for *plugins*! VDR itself will have nothing to do with this file!
2.) the file should be included in VDR's Makefile after including Make.config (maybe that idea should be dropped in favor of 5.a) as any VDR related option can be put into Make.config anyway).
See 1.).
3.) the file should be included into plugin Makefiles after having set PLUGIN and VERSION to be able to have some plugin-/version-dependent configuration.
Agreed.
4.) the file is optional -- maybe a template file like Make.config.template could indicate that there is something available for tuning.
5.) how do we name the file? 5.a) plugins.conf (doesn't fit perfectly for 2., to be a common file for VDR too)
No need, see 1.).
5.b) Make.common 5.c) local.conf 5.d) Make.config.local
6.) where do we put the file? 6.a) kls suggested /etc/vdr at a random shot 6.b) I would like to put it next to Make.config 6.c) use pkg-config to determine path (defaults to VDRDIR)
Can't we just agree on a fixed place for this file? Does it really have to be somewhere else on every system?
I suggest to put the lines
PLGCFG ?= /etc/vdr/plugins.conf -include $(PLGCFG)
into each plugin's Makefile and that's it.
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
I've been doing things with Make.config too, and would like it to be available again. My plugins usually followed this pattern:
-include $(VDRDIR)/Make.global -include $(VDRDIR)/Make.config -include Make.config
so you always had the chance to have optional control without patching makefiles.
The global Make.config had lines like this:
ifeq ($(PLUGIN),someplugin) ... endif
to do build configuration for some plugins, or to force-off some warnings or fix certain compile issues, or even add distribution-specific quirks. (building for different debian releases from same source)
So I'm in for a central method to do configuration, and not having to patch every plugin makefile and distribute several local Make.config files.
Am 25.12.2012 21:07, schrieb Klaus Schmidinger:
On 25.12.2012 20:47, Reinhard Nissl wrote:
1.) there is a need for a common make configuration file for both VDR and plugins.
No, only for *plugins*! VDR itself will have nothing to do with this file!
Should be ok to have an Make-plugin.config, as long as all vdr relevant options from Make.config get passed on into vdr.pc and can be re-read by the plugin. Directly accessing Make.config is way easier than reconstructing it, though. Speaking of all, I wonder whether some plugin out there used PREFIX or MANDIR, these are now off-limits.
Oh, and by the way, with introducing $(CWD) some previously relative paths got hard coded, so moving these builds around or accessing them from different mount points might now be broken. For example, my default lib dir changed from ./PLUGINS/lib to /usr/src/pc/vdr/vdr-1.7.34/PLUGINS/lib, which only makes sense within a single virtual machine that cannot even run VDR at all. I'll have to add some overrides for that.
Also, this needs some thoughts on compatibility, as I prefer to provide ONE source code package, no matter what VDR version it is for. I won't support X different plugin versions for Y different VDR versions. Don't make me choose between dropping pre-1.7.34 or post-1.7.33, you might not like the outcome. Right now, the old Makefiles luckily just do compile after all.
I suggest to put the lines
PLGCFG ?= /etc/vdr/plugins.conf -include $(PLGCFG)
into each plugin's Makefile and that's it.
Please, prettyprettyprettyplease NOT /etc. Source code should compile from within its source folder, and not interfere with global configuration. I don't want to sudo scripts that prepare sources for compiling, and I want multiple source codes in parallel to build independently, without swapping files in /etc each time.
Am 26.12.2012 15:54, schrieb Manuel Reimer:
then just add your options to your "Make.config" as you did in the past, but prefix them with an "export ". Something like:
export PLUGIN_OPTION = "any_value"
This way the options reach the plugin Makefiles if you do your "make plugins" as the global VDR Makefile exports the value.
Especially for development, make plugins is waaay to heavyweight. Until now it was easily possible to enter the plugin source directory and just do an make all. (for my plugins, even a simple make will do.) Your suggestion depends on passing through VDR's makefile first to realize these options.
Cheers,
Udo
On 26.12.2012 20:19, Udo Richter wrote:
... Oh, and by the way, with introducing $(CWD) some previously relative paths got hard coded, so moving these builds around or accessing them from different mount points might now be broken. For example, my default lib dir changed from ./PLUGINS/lib to /usr/src/pc/vdr/vdr-1.7.34/PLUGINS/lib, which only makes sense within a single virtual machine that cannot even run VDR at all. I'll have to add some overrides for that.
The attached patch changes the VDR Makefile back to using relative paths if the plugins are built locally. The patch also contains
- Making sure that plugins include the VDR header files from the actual VDR source directory when doing "make plugins" (suggested by Christoper Reimer). - Increased the version numbers of all plugins to reflect the recent Makefile changes. - If set, DVBDIR is now conveyed to plugins via the CFLAGS. - Removed some redundancy from Make.config.template. - Changed "==" to "=" in the Makefile to make it POSIX style. - Now using targets "install-lib" and "install-i18n" when building plugins locally. - Added MANDIR to the vdr.pc file, so that plugins that need it can retrieve it via MANDIR = $(DESTDIR)$(call PKGCFG,mandir). - Using relative paths again when building plugins locally (by request of Udo Richter).
...still considering what to do with the plugin configuration stuff. Currently I tend to put a "plgcfg" entry into vdr.pc, since apparently everybody wants this to be somewhere else. I'm just glad Linux distribution managers don't build cars - otherwise we would most likely be long dead before we find the brake pedal... ;-)
Klaus
Klaus Schmidinger wrote:
...still considering what to do with the plugin configuration stuff. Currently I tend to put a "plgcfg" entry into vdr.pc, since apparently everybody wants this to be somewhere else. I'm just glad Linux distribution managers don't build cars - otherwise we would most likely be long dead before we find the brake pedal... ;-)
Distributors don't need global plugin configuration. At least not for any distribution, I know.
The usual way is to have all stuff, that belongs to one "package", in one place. Noone edits the build relevant stuff for the base "VDR" package if a new plugin has to be packaged.
So: No need for global plugin configuration in this case.
To anyone who wants that "global configuration": Why do you need it and don't you think an alternative way will do just as well?
Yours
Manuel
On 27.12.2012 17:22, Manuel Reimer wrote:
Klaus Schmidinger wrote:
...still considering what to do with the plugin configuration stuff. Currently I tend to put a "plgcfg" entry into vdr.pc, since apparently everybody wants this to be somewhere else. I'm just glad Linux distribution managers don't build cars - otherwise we would most likely be long dead before we find the brake pedal... ;-)
Distributors don't need global plugin configuration...
This was more like a general rant about Linux distributions all wanting there files in different locations.
Klaus
Klaus Schmidinger wrote:
This was more like a general rant about Linux distributions all wanting there files in different locations.
This is common on most Unix systems. There are common paths where specific types of files should be placed to. If you are used to the common paths, then you'll find the files, you are looking for, without the need to have to look into the programs documentation.
The alternative would be that everyone places stuff to wherever they want which would result in noone knowing about where to search for a specific library on the system. So maybe most software would be linked statically or would bring their own version of $LIBRARY. It would be a total mess to update this if a security hole in a popular library has to be patched...
Yours
Manuel
On 27.12.2012 17:43, Manuel Reimer wrote:
Klaus Schmidinger wrote:
This was more like a general rant about Linux distributions all wanting there files in different locations.
This is common on most Unix systems. There are common paths where specific types of files should be placed to. If you are used to the common paths, then you'll find the files, you are looking for, without the need to have to look into the programs documentation.
But these "common paths" tend to be different on the various systems, and that's what bothers me.
But we're getting OT here...
Klaus
I'm just glad Linux distribution managers don't build cars - otherwise we would most likely be long dead before we find the brake pedal... ;-)
As a distribution manger I have to disagree ;) All I'm doing now, is to wait til you find a solution which won't be changed within the next five days and then I put my distribution around it ;) But I think I have to wait til V2, there are way too much changes at the moment :)
Am 27.12.2012 19:11, schrieb Helmut Auer:
I'm just glad Linux distribution managers don't build cars - otherwise we would most likely be long dead before we find the brake pedal... ;-)
As a distribution manger I have to disagree ;) All I'm doing now, is to wait til you find a solution which won't be changed within the next five days and then I put my distribution around it ;)
Something similar I wrote in the portal. So Full ACK.
Gerald
!DSPAM:50dc90eb87784772790529!
... there are way too much changes at the moment :)
FullAck, but the number of changes are not the issue, it's more the sustainability and the time frame within the changes. Looking to the last 5 versions, each of them do look allmost like a complete new version. There is allmost no time for other developers (plugins, addons and distros) to react to them and the worse, they don't now if their work is valid for the next vdr developer version. If you want to stop any development around VDR, go ahead like this ...
But don't forget, you don't make a solution liek VDR a success or BBS like vdr-portal only with a few "make; make install" users. Over 95% of VDR users are using a distribution.
=== Kind regards fnu
On Thu, Dec 27, 2012 at 10:20 AM, fnu vdr@auktion.hostingkunde.de wrote:
... there are way too much changes at the moment :)
FullAck, but the number of changes are not the issue, it's more the sustainability and the time frame within the changes. Looking to the last 5 versions, each of them do look allmost like a complete new version. There is allmost no time for other developers (plugins, addons and distros) to react to them and the worse, they don't now if their work is valid for the next vdr developer version. If you want to stop any development around VDR, go ahead like this ...
Keep in mind, all these changes are occurring in the _developer_ version of VDR, not stable. If package maintainers choose to use developer rather than stable versions, they should expect things like this. Maybe the problem isn't the changes, it's that they've picked the wrong version to work with. Just a thought.
But don't forget, you don't make a solution liek VDR a success or BBS like vdr-portal only with a few "make; make install" users. Over 95% of VDR users are using a distribution.
I completely disagree with you claiming "over 95% of VDR users are using a distribution". Most of the users I talk to regularly, or observe in various forums do not use pre-made distributions, they compile VDR themselves so they have full control over what patches (if any) are being applied, how it's set up, etc. And of those users, most don't even install VDR, they simply run it from the source dir. You need to remember, VDR was a success long before these pre-made distributions so to try crediting VDRs success _to_ them is insane. I'm not really knocking pre-made VDR -- there are some users who like it. But, VDR did just fine before them, and will continue doing just fine long after those projects get abandoned/retire/EOL/whatever.
On 27.12.2012 13:21, VDR User wrote:
On Thu, Dec 27, 2012 at 10:20 AM, fnu vdr@auktion.hostingkunde.de wrote:
... there are way too much changes at the moment :)
FullAck, but the number of changes are not the issue, it's more the sustainability and the time frame within the changes. Looking to the last 5 versions, each of them do look allmost like a complete new version. There is allmost no time for other developers (plugins, addons and distros) to react to them and the worse, they don't now if their work is valid for the next vdr developer version. If you want to stop any development around VDR, go ahead like this ...
Keep in mind, all these changes are occurring in the _developer_ version of VDR, not stable. If package maintainers choose to use developer rather than stable versions, they should expect things like this. Maybe the problem isn't the changes, it's that they've picked the wrong version to work with. Just a thought.
When software advances at glacial speeds(*) reality tends compensate for that over time.
See the permanent "Beta"-marking that many Google-Services tended to have in the past.
*: The timestamp of the 1.6.0 release (a.k.a. vdr-current.tar.bz2) on ftp.tvdr.de is: 23.03.2008,
Am 27.12.2012 22:21, schrieb VDR User:
On Thu, Dec 27, 2012 at 10:20 AM, fnu vdr@auktion.hostingkunde.de wrote:
But don't forget, you don't make a solution liek VDR a success or BBS like vdr-portal only with a few "make; make install" users. Over 95% of VDR users are using a distribution.
I completely disagree with you claiming "over 95% of VDR users are using a distribution". Most of the users I talk to regularly, or observe in various forums do not use pre-made distributions, they compile VDR themselves so they have full control over what patches (if any) are being applied, how it's set up, etc.
I would never come to the idea to say that over 95% of the VDR users use a distribution and I even would not say the opposite, because I really have no idea.
But what makes you so sure that it is wrong? Do you think you know more than 5% of all VDR users?
Gerald
!DSPAM:50dccbaa99813830873357!
One last question:
Am 27.12.2012 22:21, schrieb VDR User:
And of those users, most don't even install VDR, they simply run it from the source dir.
So, real VDR user don't need the install Target in the makefile and distributors, at least me, don't need it too. It seems there must be another group of VDR users there that need that stuff. How large might be this group?
Gerald
!DSPAM:50dcce26100191898546622!
Keep in mind, all these changes are occurring in the _developer_ version
of VDR, not stable.
Oh damn, I did not even realize this ... ^^
Nobody really want to use VDR 1.6.0 anymore these days, in Europe we would not be able to watch HDTV. Facing this fact VDR 1.7.3+ is more than just a developer playground.
All plugins for VDR 1.6.0 are already saddled, for 1.7.x they need keep up with VDR's development, so that is not a question of choosing the wrong version. It can't be the right way that there is a VDR developer version, which is just usable from vanilla source w/o any addon and hardly in any other environment. How should anybody test it for real life, assuming that the next version does again deny all work again ... ?
I don't deny changes, quite the contrary, Klaus does now it, I appreciate them. But the way of the last changes, in best manner of Louis XIV, ignoring all other needs around can't be the right way.
Derek tell me, do you compile your Linux also from scratch/source? I would assume you don't do this and rather using something like Fedora, RedHat, SuSE, Debian, Gentoo etc. using comfortably the offered packages ot their repositories, even the ones from unstable sources. If I talk about distro, I do talk rather about these package offerings.
I did compile my VDR from source for many years since the year 2000/2001, but I appreciate to have it as Debian package or similar later days. I would also not compile my libreoffice from source, why, it's already there. And I like to offer up to date Ubuntu packages for interessted users.
VDR is indeed a success and my alltime HTPC favorite, thanks for it Klaus. But that is not from the users compiling from source. I do not talk about some dozens of US users compiling VDR themselfs from source. VDR start to get a huge distribution in Germany and later Europe from pre-packaged ISOs, like vdr4you, linvdr and especially c't-vdr (thanks Tobi and team). These days easyvdr, gen2vdr, MLD and yaVDR do provide OOTB VDRs for thousands of installations in Germany, Europe, maybe worldwide.
Does anybody think these users would be interssted in VDR 1.6.0 nowadays? No, they are more than happy with these VDR 1.7.x based installations, modern and capable for HDTV and they do tell this their neighbours using any crappy satellite receiver with a lot of problems ... ;-)
Linux wouldn't have been that succesfull, if Linus Torvalds would not had an ear to the needs of others, even business needs ...
=== Kind regards fnu
On 27.12.2012 23:40, fnu wrote:
... But the way of the last changes, in best manner of Louis XIV, ignoring all other needs around can't be the right way.
All I did was to accept a patch from Christopher Reimer that removed some redundancy in the Makefiles and would better isolate the plugins Makefiles from the core VDR. Sure, it's an incompatible change, but sometimes you have to make some deeper cuts, and a developer version is the place to do that. I even provided a sample patch that shows all the necessary changes to plugin Makefiles, and I am now working on integrating the input that was triggered by this change (see the patch I posted earlier today).
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...
Klaus
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. 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 :)
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
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
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
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".
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
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 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
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 vdr@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, helmut@helmutauer.de
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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
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.
On 27 Dec 2012, at 23:41, fnu vdr@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”
Dominic,
good one!
I know, a coin has always two sides, but hack, look where Linux nowadays is . ^^
Cheers
Frank
Im Auftrag von Dominic Evans Gesendet: Freitag, 28. Dezember 2012 00:47 An: VDR Mailing List Betreff: Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
On 27 Dec 2012, at 23:41, fnu 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 http://article.gmane.org/gmane.linux.kernel/1414106
Matthias Schniedermeyer: Pointing out that the last stable release of VDR having an old timestamp has nothing to do with people _choosing_ to use the developer version, which is warned and well-known to possibly contain changes that will cause problems for those expecting "stable" behavior. The advice has always been, and will always be, if you expect stable then use stable.
Gerald Dachs: I think fnu is wrong in his assumption that "over 95% of VDR users" use pre-made VDR distributions because I see no evidence of it anywhere. Not in forums, mailing lists, irc, ... Ultimately nobody knows the true answer but that doesn't mean you should look at things with blinders on that only allow you to see what you want to see.
@fnu: "Nobody really want to use VDR 1.6.0 anymore these days, in Europe we would not be able to watch HDTV. Facing this fact VDR 1.7.3+ is more than just a developer playground."
VDR 1.7.3+ _are_ developer versions no matter how many users use it, or why they do.
"It can't be the right way that there is a VDR developer version, which is just usable from vanilla source w/o any addon and hardly in any other environment."
Plugin authors have two choices.. They can 1) follow the VDR developer versions knowing that there may be many changes and require a lot of work to make their plugins work with each version, or 2) update their plugin only at stable version intervals.. Thankfully it seems #1 is the popular choice because it keeps them active and makes it highly likely their plugins will work with the next stable release at the moment it's released. But, again, choosing developer VDR means you may face the possibility that everything will break with the next version. History says this rarely happens but it could and whether or not it does shouldn't be the deciding factor in if VDR adopts a change or not. Klaus I'm sure has had many VDR growing pains over the years -- it's not exactly unreasonable to say plugin authors might have them as well.
"Derek tell me, do you compile your Linux also from scratch/source? I would assume you don't do this and rather using something like Fedora, RedHat, SuSE, Debian, Gentoo etc. using comfortably the offered packages ot their repositories, even the ones from unstable sources."
I use Debian testing and compile the following; VDR, VDR plugins I use, mplayer2, ffmpeg, the kernel, external (media_build) dvb & lirc drivers. I do not use a desktop and therefore don't waste my time with anything beyond installing xserver so my VDR boxes have a way to output video. But compiling an entire distro from scratch? No, I don't do that. I hope you're not comparing compiling VDR to compiling an entire distro because that would be dumb.
"VDR is indeed a success and my alltime HTPC favorite, thanks for it Klaus. But that is not from the users compiling from source. I do not talk about some dozens of US users compiling VDR themselfs from source."
You're not only vastly underestimating the size of the NA user base (not just the US), but you're also ignoring all the european VDR users who do not user pre-made VDR and the history VDR had before pre-made was around. Many users install pre-made packages or use something like yavdr. ....And very obviously many users do not. Pulling magical numbers out of thin air won't change that fact and neither will pretending other types of VDR users don't exist.
You think VDR is successful because of pre-made stuff. I think it was successful before that. Let's just agree to disagree. You can keep installing yavdr, I will keep compiling VDR myself, and everyone else will do whatever they do.
"Linux wouldn't have been that succesfull, if Linus Torvalds would not had an ear to the needs of others, even business needs ..."
I'm not sure why you're mentioning this. Are you implying that VDR-1.7.34 goes against the _needs_ of plugin authors? Klaus certainly takes what other people want into consideration and has implemented things that wouldn't have happened if they were based solely on his own opinion/preference/needs/wants. Lack of consideration for others isn't even an issue here so I'm not sure why you're bringing it up.
Everyone: Sorry for using this reply format but it seemed more appropriate than posting several replies in a row.
On 27.12.2012 16:55, VDR User wrote:
Matthias Schniedermeyer: Pointing out that the last stable release of VDR having an old timestamp has nothing to do with people _choosing_ to use the developer version, which is warned and well-known to possibly contain changes that will cause problems for those expecting "stable" behavior. The advice has always been, and will always be, if you expect stable then use stable.
It is, or can be, a dependency problem. If your main use-case is for e.g. provided by a plugin that only works with the lastest development-release you are more or less forced to use a development release.
Or some other example i use a self compiled VDR, but i'm also a Debian user. Debian is currently in a freeze-phase for the next stable release. So i looked which version of VDR i could install: apt-cache show vdr | grep Version Version: 1.7.28-1 There isn't even a 1.6 version to install only a single 1.7 Version. (Technically i'm on unstable, but there shouldn't be that much difference as long as Wheezy isn't released )
And this is Debian, famous for being ultraconservative when it is about stability. I'm smelling a problem of reality. When the caravan moves on ....
Linus realized that when he changed the development-model of the kernel last time some years ago: Yearlong "gaps" are a problem in reality.
I think fnu is wrong in his assumption that "over 95% of VDR users"
I'm not wrong, the users compiling VDR from scratch are far in minority. Again I'm not just talking about ready to run ISO images.
There are plenty of silent users working the packages out of Linux' distros repositories, Debian, Ubuntu, Gentoo, Fedrora etc. Many of them run VDR underneath any other HTPC solution. These users don't argue on mailing lists nor on the different forum, so nobody can hear them.
On top of these amount, there are a lot of silent users running ISO based VDRs. I assume there is still a good hundred linvdr installations out there, running their good old FF cards.
But that is not the topic here, it's more that the few maintainers of these repositories, what ever kind, are ignored in their needs to provide usable packages to these quite huge number of users. A few DIY users are more equal then even fewer distro and packaging maintainers ...
=== Kind regards fnu
On Thu, Dec 27, 2012 at 5:29 PM, fnu vdr@auktion.hostingkunde.de wrote:
I'm not wrong, the users compiling VDR from scratch are far in minority. Again I'm not just talking about ready to run ISO images.
You make this claim but the opposite is observed on mailing lists, forums, and irc. Since you're so convinced, maybe you can share some actual evidence that backs it up since taking your word for it isn't proof of anything. Or maybe your sentence was incomplete.. Did you mean to say, "I'm not wrong, the users compiling VDR from scratch are far in minority... on the yavdr forum"?
There are plenty of silent users working the packages out of Linux' distros repositories, Debian, Ubuntu, Gentoo, Fedrora etc. Many of them run VDR underneath any other HTPC solution. These users don't argue on mailing lists nor on the different forum, so nobody can hear them.
I agree that there is a huge number of silent users. I know many myself, most of which compile VDR -- the opposite of what you're claiming. Does that mean anything? Not really... Only that there are obviously many VDR users with differing VDR preferences. The difference between my view and yours is that you seem to think barely anyone outside of your own viewpoint exists..
On top of these amount, there are a lot of silent users running ISO based VDRs. I assume there is still a good hundred linvdr installations out there, running their good old FF cards.
I wouldn't assume that. I can't even name a single person who uses linvdr but at least I don't deny that they might exist.
But that is not the topic here, it's more that the few maintainers of these repositories, what ever kind, are ignored in their needs to provide usable packages to these quite huge number of users. A few DIY users are more equal then even fewer distro and packaging maintainers ...
I'm not sure why you keep pretending there's hardly even a small handful of "DIY" users when there's plenty of evidence that says otherwise. I guess you think if you say it enough, people will be hypnotized into believing it. It may be hard for you to accept but reality is that VDR has a successful life way past yavdr and `apt-get install vdr`.
users when there's plenty of evidence that says otherwise.
You did not provide any ... you also just pray your truth ...
It may be hard for you to accept but reality is that VDR has a successful
life way past yavdr and `apt-get install vdr`.
Yes, I know, I have been part of it. I still keep the same historic case of the first VDR ever, bought in 2000 after my first contact to Klaus, see pic on tvdr.de ...
So, fortunately the majority of Linux world has left the "make; make install" cave.
=== Kind regards fnu
On Thu, Dec 27, 2012 at 7:38 PM, fnu vdr@auktion.hostingkunde.de wrote:
users when there's plenty of evidence that says otherwise.
You did not provide any ... you also just pray your truth ...
This mailing list, the freebsd multimedia mailing list, forums such as vdr-portal, dvbn, and numerous others, irc channels, etc. all have many users who compile VDR themselves. It's so absurd to deny it that I'm forced to think you're just trolling with the outlandish claims you keep making.
It may be hard for you to accept but reality is that VDR has a successful
life way past yavdr and `apt-get install vdr`.
Yes, I know, I have been part of it. I still keep the same historic case of the first VDR ever, bought in 2000 after my first contact to Klaus, see pic on tvdr.de ...
So, fortunately the majority of Linux world has left the "make; make install" cave.
You must know how incredibly stupid that comment is. Anyone who thinks otherwise should google "linux make install" and be careful not to drown in the ocean of posts & messages they find. Please stop the ridiculousness -- it's not like you've provided a single shred of evidence, or a single person has taken your magical numbers & assumptions as truth. Let's not waste more mailing list space with this nonsense.
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
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
On Fri, Dec 28, 2012 at 11:19 AM, fnu vdr@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.
On 28.12.2012 00:47, Dominic Evans wrote:
On 27 Dec 2012, at 23:41, fnu <vdr@auktion.hostingkunde.de mailto:vdr@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”
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
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
On 28 December 2012 10:07, Gero geronimo013@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.
On 28 December 2012 09:29, Klaus Schmidinger Klaus.Schmidinger@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.
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.
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
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 ;-)
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.
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
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
von Manuel Reimer manuel.reimer@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
On 29.12.2012 17:52, fnu wrote:
von Manuel Reimer manuel.reimer@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
von Klaus Schmidinger Klaus.Schmidinger@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
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
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
2012/12/29 Udo Richter udo_richter@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
von Christopher Reimer c.reimer1993@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
2012/12/30 fnu vdr@auktion.hostingkunde.de:
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.
Ohh come on. There were warnings.
VDR-Portal: http://www.vdr-portal.de/board17-developer/board25-patches/115856-redundanz-... Mailinglist: http://linuxtv.org/pipermail/vdr/2012-November/026813.html
Everyone who complains now was just too proud or to ignorant to answer on one of these threads.
30.12.2012 01:08, Christopher Reimer:
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.
Okay, now I am really derailing this thread - but think a bit about that one. Why are the majority of the users German - and why does it stay that way? Is it for the greater benefit of VDR?
VDR-Portal: http://www.vdr-portal.de/board17-developer/board25-patches/115856-redundanz-...
Try pulling that one through Google Translate :)
Am 30.12.2012 01:08, schrieb Christopher Reimer:
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.
What makes you believe that? Do you have any numbers? I don't have user counts either.
I know that visitors of yavdr.org are not the same as vdr users, but they might be somehow related. Our statistics shows that the german group is with %67 of course the biggest, but far away from "almost all".
Gerald
!DSPAM:50e02a13296741317615234!
Nice 33%!!
Then tell me why was there no answer on the mailinglist thread.
No answer = everything is ok --> send patch to Klaus
2012/12/30 Gerald Dachs vdr@dachsweb.de:
Am 30.12.2012 01:08, schrieb Christopher Reimer:
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.
What makes you believe that? Do you have any numbers? I don't have user counts either.
I know that visitors of yavdr.org are not the same as vdr users, but they might be somehow related. Our statistics shows that the german group is with %67 of course the biggest, but far away from "almost all".
Gerald
!DSPAM:50e02a13296741317615234!
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
von Vidar Tyldum vidar@tyldum.com Why are the majority of the users German - and why does it stay that way?
Is it for the greater benefit of VDR?
This is not the fault of the german users, VDR is historically a "german speaking project", initiated by a german guy, used by the biggest VDR community, german, austrian and swiss people. I guess most of them don't feel save enough to write in english, they don't want to be blamed for not being nativ speaker and vdr-portal.de is far the better way to find information and solution.
You should rather ask why the rest does not join this biggest VDR forum? There are a lot of people answering in english ...
von Christopher Reimer c.reimer1993@gmail.com Then tell me why was there no answer on the mailinglist thread.
Nobody did oversea the consquences and all are surprised due to this eat and die change, obviously initiated bottomline by one person.
Again it is absolutely not against the change, it might be necessary, but not now and not in this way. I'm not anymore sure that VDR is a kind of community project, where here and there are thoughts about all participants. This number here reminds me more on George Orwells Animal Farm.
Let 1.7.3x become a stable branch and postpone this change to the next development cycle. So, everybody does get time to get saddled for this change but with an HDTV capable fallback.
=== Kind regards fnu
On Sun, Dec 30, 2012 at 4:26 AM, fnu vdr@auktion.hostingkunde.de wrote:
Why are the majority of the users German - and why does it stay that way?
Is it for the greater benefit of VDR?
This is not the fault of the german users, VDR is historically a "german speaking project", initiated by a german guy, used by the biggest VDR community, german, austrian and swiss people. I guess most of them don't feel save enough to write in english, they don't want to be blamed for not being nativ speaker and vdr-portal.de is far the better way to find information and solution.
You should rather ask why the rest does not join this biggest VDR forum? There are a lot of people answering in english ...
That's no mystery at all. When you go to vdrportal, easily the vast majority of posts are in german. That doesn't make it appear as an english-friendly forum and is an immediate turn-off. How are users supposed to search for what they're looking for? Maybe they should just ask the same questions over and over again, probably getting bashed for doing so and not "searching" the forum for previous answers to the same questions. Next, NA users tend to have questions regarding NA-specific issues, which german users tend to not have answers to since its not something they have to deal with. That's just two of the most common issues, but certainly not all of them.
I know TONS of english-speaking users who have visited vdrportal and most of them haven't returned because the little sprinkles of english posts aren't enough to make them feel comfortable asking questions, getting answers, or feeling like a welcome visitor/member. And honestly, do germans want to have to keep translating everything for non-german users when they're asked? I doubt it. As good as vdrportal is as a VDR resource, the language barrier _is_ a problem for english speakers.
As far as the mailing list, many users seem to think its for devs only and/or they don't have anything to contribute being users with nothing but questions. There are also many users who simply don't use mailing lists (or forums for that matter) either because they don't want to or because they think others will ask and they can just search for answers. I think it's unfortunate because if they did, people would have a better idea of the types of VDR users that exist, and further they would have some clue about how big non-german/non-european VDR communities exist.
Everything above is all common and has been at least as long as my own VDR history started about 10 years ago. Keep in mind, even VDR itself wasn't even NA friendly for most of its existence.
+1
ML is the most usable for French users, even if I understand a little bit German for my part, technical discussion is difficult to understand and google translator is funny sometimes applied to vdr portal.
Regarding French forum having vdr section, regarding their technical skills, user build sources and plugins, most use pre builded yavdr packages and few "needed but never discussed here" plugins
For my part, I will stay under 1.7.22 that works perfectly in HD with extended patch giving extension necessary in common use like cutterqueue, freesat epg, extended records menu etc etc .. and wait 2.0 to upgrade
This is an advice of small French user
Klaus, thanks for this nice piece of software, Keep the good job, I am very happy with my mediacenter based on vdr
Thanks
Le dimanche 30 décembre 2012 18:27:02, VDR User a écrit :
On Sun, Dec 30, 2012 at 4:26 AM, fnu vdr@auktion.hostingkunde.de wrote:
Why are the majority of the users German - and why does it stay that way?
Is it for the greater benefit of VDR?
This is not the fault of the german users, VDR is historically a "german speaking project", initiated by a german guy, used by the biggest VDR community, german, austrian and swiss people. I guess most of them don't feel save enough to write in english, they don't want to be blamed for not being nativ speaker and vdr-portal.de is far the better way to find information and solution.
You should rather ask why the rest does not join this biggest VDR forum? There are a lot of people answering in english ...
That's no mystery at all. When you go to vdrportal, easily the vast majority of posts are in german. That doesn't make it appear as an english-friendly forum and is an immediate turn-off. How are users supposed to search for what they're looking for? Maybe they should just ask the same questions over and over again, probably getting bashed for doing so and not "searching" the forum for previous answers to the same questions. Next, NA users tend to have questions regarding NA-specific issues, which german users tend to not have answers to since its not something they have to deal with. That's just two of the most common issues, but certainly not all of them.
I know TONS of english-speaking users who have visited vdrportal and most of them haven't returned because the little sprinkles of english posts aren't enough to make them feel comfortable asking questions, getting answers, or feeling like a welcome visitor/member. And honestly, do germans want to have to keep translating everything for non-german users when they're asked? I doubt it. As good as vdrportal is as a VDR resource, the language barrier _is_ a problem for english speakers.
As far as the mailing list, many users seem to think its for devs only and/or they don't have anything to contribute being users with nothing but questions. There are also many users who simply don't use mailing lists (or forums for that matter) either because they don't want to or because they think others will ask and they can just search for answers. I think it's unfortunate because if they did, people would have a better idea of the types of VDR users that exist, and further they would have some clue about how big non-german/non-european VDR communities exist.
Everything above is all common and has been at least as long as my own VDR history started about 10 years ago. Keep in mind, even VDR itself wasn't even NA friendly for most of its existence.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
As good as vdrportal is as a VDR resource, the language barrier _is_ a
problem for english speakers.
Same with this mailing list for german speakers ... and now?
or feeling like a welcome visitor/member
A little tale, if I'm in the US, I have to speak english all time. If my US friends do visit me or colleagues are staying in Germany, I also have to speak english all the time. They don't even try to speak my/our language while staying in Germany. And hey, don't think they ever welcomed me in german language ... ^^
This is just a chicken-and-egg problem, you all don't try to use it, so no information is collected or any kind of community will be set up. There is an rarly used international part, but if somebody does ask in english, she/he gets an answer in english, wherever postet. Time and patience could solve a lot, even losing shyness of nativ german speakers to answer in english, but this up to you all ...
Unfortunately the search function of vdr-portal sucks IMHO, so in all languages, better use google w/ "site:vdr-portal.de what-you-search-for".
=== Kind regards fnu
On Sun, Dec 30, 2012 at 3:54 PM, fnu vdr@auktion.hostingkunde.de wrote:
As good as vdrportal is as a VDR resource, the language barrier _is_ a
problem for english speakers.
Same with this mailing list for german speakers ... and now?
I don't recall any german speakers ever expressing a problem that this mailing list is primarily english. Regardless of whether germans have a problem with this mailing list or not, I think it's certainly appropriate that it is primarily english for the simple fact english is a common language spoken by many non-english native speakers. There are many users and devs here from many different countries and thankfully they have english as a common means to communicate. My understanding is that english is taught as a multi-year requirement in many foreign countries. There are school districts here that require 2 years of foreign language, while most it's optional. Of the people who take foreign language, spanish is easily the first choice considering we have such a large hispanic population. Behind that is probably french, then japanese. German isn't very popular here I assume because we don't have many large german communities.
or feeling like a welcome visitor/member
A little tale, if I'm in the US, I have to speak english all time. If my US friends do visit me or colleagues are staying in Germany, I also have to speak english all the time. They don't even try to speak my/our language while staying in Germany. And hey, don't think they ever welcomed me in german language ... ^^
Personally I don't think it's much to ask to learn to greet a foreign friend in their native language but I guess your friends disagree.
This is just a chicken-and-egg problem, you all don't try to use it, so no information is collected or any kind of community will be set up. There is an rarly used international part, but if somebody does ask in english, she/he gets an answer in english, wherever postet. Time and patience could solve a lot, even losing shyness of nativ german speakers to answer in english, but this up to you all ...
I hope you don't misunderstand, I wasn't complaining that vdrportal isn't english-friendly. I was simply giving a few quick reasons why it _appears_ to be unfriendly for english speakers and why (we) don't use the site. It's the same reason why english speakers don't use the russian vdr forums, the french forums, the spanish forums, etc. Unfortunately vdrportal will never be a good home for english users in the same way those russian, french, spanish, etc. forums won't either. Look at how many of the actual english posts don't even have replies, or what little replies there are that don't actually help. It shouldn't be a wonder why you see tumbleweeds in the `international` section of vdrportal. That being said, (we) still manage to get VDR running thanks to the english-friendly forums that exist.
Unfortunately the search function of vdr-portal sucks IMHO, so in all languages, better use google w/ "site:vdr-portal.de what-you-search-for".
If you speak german, I agree. If you speak english then this mailing list or one of the english forums are probably a better choice.
by VDR User user.vdr@gmail.com but I guess your friends disagree.
Not only my friends, e.g. one guy of an international customer, a US citizen living in Germany since 10-15 years, is not willing to talk in german with us. Just another example, but even our famous foreign workers from all over Europe do better here, only the french do worse ... ;-)
I hope you don't misunderstand, I wasn't complaining that vdrportal isn't
english-friendly.
No, no, I got it. What is the most famous english speaking forum?
=== Kind regards fnu
On Mon, Dec 31, 2012 at 6:54 AM, fnu vdr@auktion.hostingkunde.de wrote:
Not only my friends, e.g. one guy of an international customer, a US citizen living in Germany since 10-15 years, is not willing to talk in german with us. Just another example, but even our famous foreign workers from all over Europe do better here, only the french do worse ... ;-)
I couldn't imagine living in a foreign country for that long and not learning the native language there. I don't see how you could avoid it unless you never left your house!
I hope you don't misunderstand, I wasn't complaining that vdrportal isn't
english-friendly.
No, no, I got it. What is the most famous english speaking forum?
One of the most popular ones is definitely dvbn.
31.12.2012 00:54, fnu:
As good as vdrportal is as a VDR resource, the language barrier _is_ a
problem for english speakers.
Same with this mailing list for german speakers ... and now?
English isn't just for the British and Americans. I realize that if I start a VDR forum/mailing-list and require Norwegian as language, the community would be fairly limited.
Don't get me wrong, doing user support in native languages helps extend the userbase, but if you want a broad developer community then the language of choice should be English.
vdr-portal.de has everything in German, you got to be pretty ballsy to start an English thread there. You have to trust the Google Translate just to find out which sub-forum to post in - and you then still risk posting the wrong place and getting flamed.
It would be nice to hear what Klaus prefers as the main development channel (notice: *main* development channel, not the only channel).
And if vdr-portal.de would do something to stimulate non-German speakers to participate, that would be great. Either some statements or a seperate part of the forum - with English titles.
On 31.12.2012 09:29, Vidar Tyldum wrote:
... It would be nice to hear what Klaus prefers as the main development channel (notice: *main* development channel, not the only channel).
Well, I always considered the VDR mailing list to be the main development channel. But with the recent "shitstorm" I'm having second thoughts...
Klaus
Den 31.12.2012 09:35, skrev Klaus Schmidinger:
Well, I always considered the VDR mailing list to be the main development channel. But with the recent "shitstorm" I'm having second thoughts...
Take it as a compliment.
It just goes to show how many have come to rely on VDR and that there is an active community around it. I mean, a shitstorm about Makefile details - how is that bad?
Your baby is growing up, I guess ;) I know I rely on it every day and really appreciate it. Thanks, by the way.
Well, I always considered the VDR mailing list to be the main development channel. But with the recent "shitstorm" I'm having second thoughts...
Klaus
Please don't leave. I don't speak english good enough to write a better reply here. :-)
Regards, Cedric
von Klaus Schmidinger But with the recent "shitstorm" I'm having second thoughts...
Hmm, I had also read shitstorms, this does have a different quality. I would also take it positiv, nobody is questioning your execellent work, in contrary, a lot of do take part of it and are interessted in. So, controversial discussions are sometimes necessary ...
Who did post Linux Torvalds words as an example ... ?
=== Kind regards fnu
On Mon, Dec 31, 2012 at 12:35 AM, Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
It would be nice to hear what Klaus prefers as the main development channel (notice: *main* development channel, not the only channel).
Well, I always considered the VDR mailing list to be the main development channel. But with the recent "shitstorm" I'm having second thoughts...
People are passionate about the things they love, even if they don't always show it in the best way possible! ;)
Am 30.12.2012 01:08, schrieb Christopher Reimer:
2012/12/29 Udo Richter udo_richter@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.
That was about a redundancy in Make.config and Make.global, and concludes to swap the include order of them. There's no word in it on dropping Make.config completely, and no word on introducing new mandatory make install targets or redefining the existing make all.
I wonder why I didn't see that coming. ;)
Cheers,
Udo
Al 30/12/12 01:08, En/na Christopher Reimer ha escrit:
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.
Oh, if vdr is only intended for german speaking users, is there a good alternative for the rest of us?
Bye
Am 01.01.2013 13:40, schrieb Luca Olivetti:
Al 30/12/12 01:08, En/na Christopher Reimer ha escrit:
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.
Oh, if vdr is only intended for german speaking users, is there a good alternative for the rest of us?
It's not, noone said that.
I (as a german) am sad, but can understand, that posting at vdr-portal in english is something complicated (or whatever the right word is, usually I write mails in english with dict.leo.org in an open browser). And I'm also sad, that many "vdr-gurus" are just active at vdr-portal and not at this mailing list. The older ones of us (I'm nearly 40 and think that I'm between the "young, wild ones" and "the wise elder" :-), tending to the older ones as I'm using computers since 25 years now) have grown up with mailing lists, newsgroups etc. For the younger ones (I don't want to flame anybody, just want to show a cliche) the "Internet" is equivalent to WWW. So they have grown up with forums like vdr-portal. I must confess that normally threads at a forum are easier to read and understand as mailing list threads in any mail-archive. First you have to found such an archive (or have to know that something like that even exists) and then it's complicated to search or even browse the archive (monthly indexes etc.).
This is an invitation: Please create more posts in english at vdr-portal! If a critical mass is passed it will be easier for the ones coming past us. Sure there's only a small "international" part, but it is there. And of course there will be "idiots", you got them everywhere, even at this mailing list. :) I promise if I have something valuable to say to an question asked in english I will give my best and will answer it.
But I can't do it on my own, please help me.
Happy New Year BTW... :) Maybe this will be a New Year'S pledge for some of us...
Lars.
On Tue, Jan 1, 2013 at 8:52 PM, Lars Hanisch dvb@flensrocker.de wrote:
This is an invitation: Please create more posts in english at vdr-portal! If a critical mass is passed it will be easier for the ones coming past us. Sure there's only a small "international" part, but it is there. And of course there will be "idiots", you got them everywhere, even at this mailing list. :) I promise if I have something valuable to say to an question asked in english I will give my best and will answer it.
I can second Lars here, following my English post on vdr-portal we worked together to fix rotorng with later versions of VDR in yavdr 0.5.0.
Perhaps a sticky at the top of the forum discussing and encouraging the use of English for non-German speaking users would help and giving some guidance on the best way to approach it, so as to avoid flames.
Den 02.01.2013 15:54, skrev Morfsta:
Perhaps a sticky at the top of the forum discussing and encouraging the use of English for non-German speaking users would help and giving some guidance on the best way to approach it, so as to avoid flames.
Yes, please! Or just "It's OK to post in English / Es sind OK zum Englisch schreibe"
(the German part is probably horribly wrong, but it's all I remember from my German class many winters ago... ;)
Am 02.01.2013 19:19, schrieb Vidar Tyldum:
Den 02.01.2013 15:54, skrev Morfsta:
Perhaps a sticky at the top of the forum discussing and encouraging the use of English for non-German speaking users would help and giving some guidance on the best way to approach it, so as to avoid flames.
Yes, please! Or just "It's OK to post in English / Es sind OK zum Englisch schreibe"
(the German part is probably horribly wrong, but it's all I remember from my German class many winters ago... ;)
"Es ist OK, in Englisch zu schreiben", just to fresh up your mind... :)
Lars.
I couldn't realize that there are so many non-German VDR users.
I personally don't like to write English. Not because I hate the language, more because I'm worried to do something wrong (grammer, tenses etc.)
Christopher
I couldn't realize that there are so many non-German VDR users.
I personally don't like to write English. Not because I hate the language, more because I'm worried to do something wrong (grammer, tenses etc.)
Christopher
Don't worry, as long as we understand you, it's ok. And if we don't understand you, it's not a big thing to ask what you mean. :-)
Regards, Cedic
On Wed, Jan 2, 2013 at 12:42 PM, Christopher Reimer c.reimer1993@gmail.com wrote:
I couldn't realize that there are so many non-German VDR users.
On one hand I guess I understand considering Germany is VDR's birthplace and has strong support there. But on the other hand, if VDR is so popular with germans, why wouldn't it be popular with non-germans? I've been a part of the NA VDR community for around 10+ years so it's non-German popularity isn't news to me. To be honest, I was surprised to find that VDR even has a following in Mexico too. Logically it shouldn't be surprising that VDR is popular anywhere since it's a great piece of software! :)
I personally don't like to write English. Not because I hate the language, more because I'm worried to do something wrong (grammer, tenses etc.)
I have heard other people say the same but probably 99.9% of english-speakers don't care about that. VDR help forums is the last place anyone should put on their grammar police uniform. Who cares as long as we can understand each other or it's ok to ask questions.
On 01/01/2013 09:52 PM, Lars Hanisch wrote: [...]
I must confess that normally threads at a forum are easier to read and understand as mailing list threads in any mail-archive. First you have to found such an archive (or have to know that something like that even exists) and then it's complicated to search or even browse the archive (monthly indexes etc.).
Just FYI, even if many ML readers may do something similar already. One can actually disable email delivery of this ML and read it through nntp at news.gmane.org, this way one can more easily have an overview of threads, and even with email delivery disabled, still post directly to the ML instead of nntp.
Lucian
Am 27.12.2012 19:11, schrieb Helmut Auer:
I'm just glad Linux distribution managers don't build cars - otherwise we would most likely be long dead before we find the brake pedal... ;-)
As a distribution manger I have to disagree ;) All I'm doing now, is to wait til you find a solution which won't be changed within the next five days and then I put my distribution around it ;) But I think I have to wait til V2, there are way too much changes at the moment :)
P.S: That doesn't mean you should hurry up to find a solution, I can live very well with former VDR versions, these are all great for getting a stable PVR at home - Thanks Klaus !
-
cedric.dewijs＠telfort.nl -
Christopher Reimer -
Dominic Evans -
Dominique -
fnu -
Gerald Dachs -
Gero -
Helmut Auer -
Joerg Bornkessel -
Klaus Schmidinger -
Lars Hanisch -
Luca Olivetti -
Lucian Muresan -
Manuel Reimer -
Marx -
Matthias Schniedermeyer -
Morfsta -
Reinhard Nissl -
Timothy D. Lenz -
Udo Richter -
VDR User -
Vidar Tyldum