[DISCUSSION,REQUEST] reintroduce a common make configuration file in VDR-1.7.35

  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.
  

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 !
  

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 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”

http://article.gmane.org/gmane.linux.kernel/1414106
  

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.
  

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
  

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”
>
> http://article.gmane.org/gmane.linux.kernel/1414106

Well, Linus apparently has very strong feelings about this.
However, nowhere in that posting does it say

   IF YOU BREAK USERSPACE I HATE YOU AND YOU ARE A TERRIBLE PERSON

So did *you* (Dominic) just make that up? I'm asking because your
posting looks just like a direct quotation from Linus, and I have
a hard time imagining a renowned person like Linus Torvalds to say
something like that.

Not breaking userspace is, of course, the right thing to do in a *stable*
version of any software. But if this means that you can't do anything new
in a *developer* version, then I guess this means we should rather stop
doing any further development and just sit on what we have. But that would
cause people complaining about a lack of innovation, I guess...

Klaus
  

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 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.
  

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.
  

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
  

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
  

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 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.
  

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".
  

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?
+1

Gerald

!DSPAM:50ddc50a174441059718148!
  

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.
  

> 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.
  

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
  

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
  

>
> 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
  

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 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
  

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
  

> 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
  

> 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
  

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
  

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-in-der-make-config-und-make-global/
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-in-der-make-config-und-make-global/

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
  

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
  

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.
  

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
  

> 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
  

> 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! ;)
  

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.
  

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