Initial scan files troubles and brainstorming
Hello list,
I was talking to someone over at tvheadend and was told that the linux-media initial scan files tend to be often very out dated. Also when newer files are submitted, requests to merge them are simply being ignored. Obviously I have zero proof to back those claims. True or not, they have decided to keep a local copy and try to keep that up to date as possible. One of the reasons to take this approach, is because major distro's also do it in this way.
This obviously results in a duplication of work and since it's factual data really wasted resources, no central repository of said factual data, but spread and makes it confusing on top of that for users of this data.
Now I don't know the proper solution or if it really is a problem. Well it appears to be so I guess ;)
Something that comes to mind, is to split off the initial scan files from the dvb-apps package and have a seperate git tree for it, like for example the firmware git tree. I feel this has several advantages over the current setup.
One could have /usr/share/dvb/ as a git tree and simply pull to have an up to date tree.
Initialscan file 'users (as in developers)' can more easily clone it and do pull requests.
Possibly more lenient commit access, e.g. allow a 'trusted' developer of a dvb project to have commit rights, without much risk of breaking any source code. Other things I haven't thought of yet.
Since there really isn't a 'stable' release, current trunk can be considered the go to release, unverified changes could live in a branch?
Again, if everybody can firmly claim there is no problem and that the initial scanfiles are updated nearly when an actually change takes place, then we should try convince downstream maintainers of course.
Anyway, this is just something that was on my mind and wanted some feedback on.
Oliver
Unfortunatly, I have had zero replies.
So why bring it up again? On 2012/11/30 Jakub Kasprzycki provided us with updated polish DVB-T frequencies for his region. This has yet to be merged, almost 3 weeks later.
While I know people are busy and merging frequency updates doesn't seem critical, for people who somewhat depend on them, the sooner, the better.
Since I didn't expect anybody to actually do the work, just was asking for your thoughts, I've done the work. I've setup a repository and purged all unrelated files. All history should have been preserved.
I'll quickly repeat why I think this approach would be quite reasonable.
* dvb-apps binary changes don't result in unnecessary releases
* frequency updates don't result in unnecessary dvb-app releases
* Less strict requirements for commits (code reviews etc)
* Possibly easier entry for new submitters
* much easier to package (tag it once per month if an update was)
* Separate maintainer possible
* just seems more logical to have it separated ;)
This obviously should find a nice home on linuxtv where it belongs!
Here is my personal repository with the work I mentioned done.git://git.schinagl.nl/dvb_frequency_scanfiles.git
If an issue is that none of the original maintainers are not looking forward to do the job, I am willing to take maintenance on me for now.
Anyway, hopefully this time we can get some form of discussion going :)
Oliver
Quoted 46 lines · Oliver Schinagl
Hello list,
I was talking to someone over at tvheadend and was told that the linux-media initial scan files tend to be often very out dated. Also when newer files are submitted, requests to merge them are simply being ignored. Obviously I have zero proof to back those claims. True or not, they have decided to keep a local copy and try to keep that up to date as possible. One of the reasons to take this approach, is because major distro's also do it in this way.
1
This obviously results in a duplication of work and since it's factual data really wasted resources, no central repository of said factual data, but spread and makes it confusing on top of that for users of this data.Now I don't know the proper solution or if it really is a problem. Well it appears to be so I guess ;)
Something that comes to mind, is to split off the initial scan files from the dvb-apps package and have a seperate git tree for it, like for example the firmware git tree. I feel this has several advantages over the current setup.
One could have
/usr/share/dvb/as a git tree and simply pull to have an up to date tree.
Initialscan file 'users (as in developers)' can more easily clone it and do pull requests.
Possibly more lenient commit access, e.g. allow a 'trusted' developer of a dvb project to have commit rights, without much risk of breaking any source code.
Other things I haven't thought of yet.
Since there really isn't a 'stable' release, current trunk can be considered the go to release, unverified changes could live in a branch?Again, if everybody can firmly claim there is no problem and that the initial scanfiles are updated nearly when an actually change takes place, then we should try convince downstream maintainers of course.
Anyway, this is just something that was on my mind and wanted some feedback on.
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 27 lines · Jonathan McCrohan
Hi Oliver,
Quoted 1 line · Oliver Schinagl
Unfortunatly, I have had zero replies.
Apologies. I wasn't subscribed to linux-media. I am now.
Quoted 6 lines
So why bring it up again? On 2012/11/30 Jakub Kasprzycki provided us with updated polish DVB-T frequencies for his region. This has yet to be merged, almost 3 weeks later.
While I know people are busy and merging frequency updates doesn't seem critical, for people who somewhat depend on them, the sooner, the better.
I can relate. I currently have two patch files that I am trying to get merged myself I have been contacting Manu and Christoph) directly because previous attempts at posting to linux-media were left unattended for a good period of time.
Quoted 10 lines
I'll quickly repeat why I think this approach would be quite reasonable.
* dvb-apps binary changes don't result in unnecessary releases
* frequency updates don't result in unnecessary dvb-app releases
* Less strict requirements for commits (code reviews etc)
* Possibly easier entry for new submitters
* much easier to package (tag it once per month if an update was)
* Separate maintainer possible
* just seems more logical to have it separated ;)
Quoted 5 lines
Quoted 1 line
This obviously should find a nice home on linuxtv where it belongs!
I like this approach, but I'm afraid that decoupling dvb-apps and scan files may result in distributions paying less attention to scan files. At the moment, they are forced to update the scan files when a new release of dvb-apps appears.
So if no code changes are needed/done, but scan files are updated, a new dvb-apps release needs to be made?
That also results in grief for packagers. Packages need to be made but more importantly tested against many combinations. While the changes (binary anyway) would be trivial/non-existant, it would result in annoyance for packagers and could even be ignored.
scanfiles could be packaged and released just as easily and since there are applications already out there, that do not even use or need dvb-apps, it makes sense to seperate them. TVheadend for example does not need dvb-apps in any form and i'm sure there's more.
So it goes both ways :p
Quoted 8 lines
Quoted 3 lines
If an issue is that none of the original maintainers are not looking forward to do the job, I am willing to take maintenance on me for now.
To be honest, I think the current system works okay. I think more people just need to be given hg commit access. This would solve the current delays.
Jon
Quoted 1 line · Oliver Schinagl
Unfortunatly, I have had zero replies.
Hmm, it's sad there is a silence in this thread from linux-media guys :/.
Quoted 3 lines
So why bring it up again? On 2012/11/30 Jakub Kasprzycki provided us with updated polish DVB-T frequencies for his region. This has yet to be merged, almost 3 weeks later.
I sent a patch for cz data too:
https://patchwork.kernel.org/patch/1844201/
Quoted 5 lines
I'll quickly repeat why I think this approach would be quite reasonable.
* dvb-apps binary changes don't result in unnecessary releases
* frequency updates don't result in unnecessary dvb-app releases
* Less strict requirements for commits (code reviews etc)
Well the code should be reviewed still. See commit a2e96055db297 in your repo, it's bogus. The freq added is in kHz instead of MHz.
Quoted 4 lines
* Possibly easier entry for new submitters
* much easier to package (tag it once per month if an update was)
* Separate maintainer possible
* just seems more logical to have it separated ;)
The downside is you have to change the URL in kaffeine sources as kaffeine generates its scan file from that repo (on the server side and the client downloads then http://kaffeine.kde.org/scanfile.dvb.qz).
Quoted 1 line
This obviously should find a nice home on linuxtv where it belongs!
At best.
Quoted 5 lines
Here is my personal repository with the work I mentioned done.
git://git.schinagl.nl/dvb_frequency_scanfiles.gitIf an issue is that none of the original maintainers are not looking forward to do the job, I am willing to take maintenance on me for now.
Ping? Anybody? I would help with that too as I hate resending patches. But the first step I would do is a conversion to GIT. HG is demented to begin with.
Signature · 1 line
js
Quoted 3 lines · Jiri Slaby
Quoted 1 line · Oliver Schinagl
Unfortunatly, I have had zero replies.
Hmm, it's sad there is a silence in this thread from linux-media guys :/.
In their defense, they are very very busy people ;) chatter on this thread does bring it up however.
Quoted 6 lines
Quoted 4 lines
So why bring it up again? On 2012/11/30 Jakub Kasprzycki provided us with updated polish DVB-T frequencies for his region. This has yet to be merged, almost 3 weeks later.
I sent a patch for cz data too:
https://patchwork.kernel.org/patch/1844201/
I see that patch lives on the kernel patchwork not the linuxtv one. Did it pass this ML? I have applied it to my tree for now.
Quoted 8 lines
Quoted 6 lines
I'll quickly repeat why I think this approach would be quite reasonable.
* dvb-apps binary changes don't result in unnecessary releases
* frequency updates don't result in unnecessary dvb-app releases
* Less strict requirements for commits (code reviews etc)Well the code should be reviewed still. See commit
a2e96055db297in your repo, it's bogus. The freq added is in kHz instead of MHz.
You are absolutely right, on both accounts. But its far less important. Yes I committed it wrongfully. I missed it. I should have spotted it. You 'fixed' this bug though ;) Reviewing is still needed. 'Rules' in that regard can always be brought up later, when things actually do change. Auto apply after a week for example?
Again, 'bugs' aren't critical and don't break functionality (but of course do cause headaches if they don't work). But updates are required to happen quickly if they do (for dvb-t at the very least). If the broadcaster changes settings, users probably want to be able to tune right away.
Quoted 8 lines
Quoted 5 lines
* Possibly easier entry for new submitters
* much easier to package (tag it once per month if an update was)
* Separate maintainer possible
* just seems more logical to have it separated ;)The downside is you have to change the URL in kaffeine sources as kaffeine generates its scan file from that repo (on the server side and the client downloads then http://kaffeine.kde.org/scanfile.dvb.qz).
IF a proper change goes through, then that's a one time change only though and while kaffeine can still use its own mirror, it's less needed :p
Quoted 13 lines
Quoted 2 lines
This obviously should find a nice home on linuxtv where it belongs!
At best.
Quoted 5 lines
Here is my personal repository with the work I mentioned done.
git://git.schinagl.nl/dvb_frequency_scanfiles.gitIf an issue is that none of the original maintainers are not looking forward to do the job, I am willing to take maintenance on me for now.
Ping? Anybody? I would help with that too as I hate resending patches. But the first step I would do is a conversion to GIT. HG is demented to begin with.
Quoted 6 lines · Oliver Schinagl
Quoted 3 lines · Jiri Slaby
Quoted 1 line · Oliver Schinagl
Unfortunatly, I have had zero replies.
Hmm, it's sad there is a silence in this thread from linux-media guys :/.
In their defense, they are very very busy people ;) chatter on this thread does bring it up however.
This is such a nice thing to say :-)
But it might be that Mauro thinks the dvb-apps maintainer should respond, but apparently there is no dvb-apps maintainer... Maybe you should ask Mauro directly to create an account for you to implement what you proposed.
Thanks,
Johannes
Quoted 4 lines · Johannes Stezenbach
Quoted 3 lines · Oliver Schinagl
Quoted 2 lines · Jiri Slaby
Quoted 1 line · Oliver Schinagl
Unfortunatly, I have had zero replies.
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
Hmm, it's sad there is a silence in this thread from linux-media guys :/.
In their defense, they are very very busy people ;) chatter on this thread does bring it up however.
This is such a nice thing to say :-)
But it might be that Mauro thinks the dvb-apps maintainer should respond, but apparently there is no dvb-apps maintainer... Maybe you should ask Mauro directly to create an account for you to implement what you proposed.
Mauro is CC'ed and I'd ask of course for this (I kinda did) but who decides what I suggested is a good idea? I personally obviously think it is ;) and even more so if dvb-apps are unmaintained.
I guess the question now becomes 'who okay's this change? Who says 'okay, lets do it this way. Once that is answered we can go from there ;)
Quoted 7 lines
Thanks,
Johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Em Wed, 09 Jan 2013 10:43:23 +0100
Oliver Schinagl <[email protected]> escreveu:
Quoted 13 lines · Johannes Stezenbach
Quoted 12 lines · Oliver Schinagl
Quoted 6 lines · Jiri Slaby
Quoted 3 lines · Oliver Schinagl
Quoted 1 line
Unfortunatly, I have had zero replies.
Hmm, it's sad there is a silence in this thread from linux-media guys :/.
In their defense, they are very very busy people ;) chatter on this thread does bring it up however.
This is such a nice thing to say :-)
But it might be that Mauro thinks the dvb-apps maintainer should respond, but apparently there is no dvb-apps maintainer... Maybe you should ask Mauro directly to create an account for you to implement what you proposed.
Quoted 6 lines
Mauro is CC'ed and I'd ask of course for this (I kinda did) but who decides what I suggested is a good idea? I personally obviously think it is ;) and even more so if dvb-apps are unmaintained.
I guess the question now becomes 'who okay's this change? Who says 'okay, lets do it this way. Once that is answered we can go from there ;)
If I understood it right, you want to split the scan files into a separate git tree and maintain it, right?
I'm ok with that.
Regards,
Mauro
Quoted 23 lines · Mauro Carvalho Chehab
Em Wed, 09 Jan 2013 10:43:23 +0100
Oliver Schinagl <[email protected]> escreveu:Quoted 13 lines · Johannes Stezenbach
Quoted 12 lines · Oliver Schinagl
Quoted 6 lines · Jiri Slaby
Quoted 3 lines · Oliver Schinagl
Quoted 1 line
Unfortunatly, I have had zero replies.
Hmm, it's sad there is a silence in this thread from linux-media guys :/.
In their defense, they are very very busy people ;) chatter on this thread does bring it up however.
This is such a nice thing to say :-)
But it might be that Mauro thinks the dvb-apps maintainer should respond, but apparently there is no dvb-apps maintainer... Maybe you should ask Mauro directly to create an account for you to implement what you proposed.Quoted 6 lines
Mauro is CC'ed and I'd ask of course for this (I kinda did) but who decides what I suggested is a good idea? I personally obviously think it is ;) and even more so if dvb-apps are unmaintained.
I guess the question now becomes 'who okay's this change? Who says 'okay, lets do it this way. Once that is answered we can go from there ;)
Quoted 7 lines
If I understood it right, you want to split the scan files into a separate git tree and maintain it, right?
I'm ok with that.
Regards,
Mauro
As a DVB maintainer, I am OK with this as well - It does indeed make sense to separate the c code sources from the regional frequency tables, and I'm sure we'll see much benefit from this change.
Regards,
Mike Krufky
Em Wed, 9 Jan 2013 06:08:44 -0500
Michael Krufky <[email protected]> escreveu:
Quoted 28 lines
Quoted 26 lines · Mauro Carvalho Chehab
Em Wed, 09 Jan 2013 10:43:23 +0100
Oliver Schinagl <[email protected]> escreveu:Quoted 13 lines · Johannes Stezenbach
Quoted 12 lines · Oliver Schinagl
Quoted 6 lines · Jiri Slaby
Quoted 3 lines · Oliver Schinagl
Quoted 1 line
Unfortunatly, I have had zero replies.
Hmm, it's sad there is a silence in this thread from linux-media guys :/.
In their defense, they are very very busy people ;) chatter on this thread does bring it up however.
This is such a nice thing to say :-)
But it might be that Mauro thinks the dvb-apps maintainer should respond, but apparently there is no dvb-apps maintainer... Maybe you should ask Mauro directly to create an account for you to implement what you proposed.Quoted 6 lines
Mauro is CC'ed and I'd ask of course for this (I kinda did) but who decides what I suggested is a good idea? I personally obviously think it is ;) and even more so if dvb-apps are unmaintained.
I guess the question now becomes 'who okay's this change? Who says 'okay, lets do it this way. Once that is answered we can go from there ;)
If I understood it right, you want to split the scan files into a separate git tree and maintain it, right?
Quoted 8 lines
Quoted 4 lines
I'm ok with that.
Regards,
MauroAs a DVB maintainer, I am OK with this as well - It does indeed make sense to separate the c code sources from the regional frequency tables, and I'm sure we'll see much benefit from this change.
Done. I created a tree for Oliver to maintain it and an account for him. I also created a new tree with just the DVB table commits to:
http://git.linuxtv.org/dtv-scan-tables.git
I kept there both szap and scan files, although maybe it makes sense to drop the szap table (channels-conf dir). It also makes sense to drop the tables from the dvb-apps tree, to avoid duplicated stuff, and to avoid troubles on distros that may want to have both packages.
Anyway, as Oliver has now access to both trees, I'll let him to handle and maintain it.
Christoph,
Thank you for all the hard work over all those years!
Happy new year,
Mauro
kaffeine.kde.org/scanfile.dvb.qz is obsolete [was: [RFC] Initial scan files troubles and brainstorming]
Quoted 3 lines · Mauro Carvalho Chehab
Christoph,
Thank you for all the hard work over all those years!
Yeah, I second this.
I have a note though. Who is going to fix the URL in kaffeine? And how often is kaffeine.kde.org/scanfile.dvb.qz updated? Is this done automatically? As it is pretty outdated (9/2011), I don't think it is... Should this be moved somewhere else?
thanks,
Signature · 1 line
js
Re: kaffeine.kde.org/scanfile.dvb.qz is obsolete [was: [RFC] Initial scan files troubles and brainstorming]
2013/1/9 Jiri Slaby <[email protected]>:
Quoted 8 lines · Mauro Carvalho Chehab
Quoted 3 lines
Christoph,
Thank you for all the hard work over all those years!
Yeah, I second this.
I have a note though. Who is going to fix the URL in kaffeine?
That belongs to me.
Quoted 3 lines
And how
often is kaffeine.kde.org/scanfile.dvb.qz updated? Is this done automatically?
No, upload happens manually. I will take care of an update.
Quoted 6 lines
As it is pretty outdated (9/2011), I don't think it is... Should this be moved somewhere else?
thanks,
--
js
Christoph
Quoted 44 lines · Mauro Carvalho Chehab
Em Wed, 9 Jan 2013 06:08:44 -0500
Michael Krufky <[email protected]> escreveu:Quoted 32 lines
Quoted 30 lines · Mauro Carvalho Chehab
Em Wed, 09 Jan 2013 10:43:23 +0100
Oliver Schinagl <[email protected]> escreveu:Quoted 14 lines · Johannes Stezenbach
Quoted 6 lines · Oliver Schinagl
Quoted 5 lines · Jiri Slaby
Quoted 4 lines · Oliver Schinagl
Quoted 1 line
Unfortunatly, I have had zero replies.
Hmm, it's sad there is a silence in this thread from linux-media guys :/.
Quoted 7 lines
Quoted 2 lines
In their defense, they are very very busy people ;) chatter on this thread does bring it up however.
This is such a nice thing to say :-)
But it might be that Mauro thinks the dvb-apps maintainer should respond, but apparently there is no dvb-apps maintainer... Maybe you should ask Mauro directly to create an account for you to implement what you proposed.Quoted 8 lines
Mauro is CC'ed and I'd ask of course for this (I kinda did) but who decides what I suggested is a good idea? I personally obviously think it
is ;) and even more so if dvb-apps are unmaintained.I guess the question now becomes 'who okay's this change? Who says 'okay, lets do it this way. Once that is answered we can go from there ;)
If I understood it right, you want to split the scan files into a separate
git tree and maintain it, right?Quoted 8 lines
Quoted 4 lines
I'm ok with that.
Regards,
MauroAs a DVB maintainer, I am OK with this as well - It does indeed make sense to separate the c code sources from the regional frequency tables, and I'm sure we'll see much benefit from this change.
Quoted 7 lines
Done. I created a tree for Oliver to maintain it and an account for him. I also created a new tree with just the DVB table commits to:
http://git.linuxtv.org/dtv-scan-tables.gitI kept there both szap and scan files, although maybe it makes sense to drop the szap table (channels-conf dir). It also makes sense to drop the tables from the dvb-apps tree, to avoid duplicated stuff, and to avoid
Being one of the maintainers:
I will keep the tables in the dvb-apps tree for the time being. Will decide to drop the config files as needed from dvb-apps. It is necessary to keep a copy of the config files for development purposes, rather than pulling from different trees.
Manu
Quoted 49 lines · Manu Abraham
Quoted 48 lines · Mauro Carvalho Chehab
Em Wed, 9 Jan 2013 06:08:44 -0500
Michael Krufky <[email protected]> escreveu:Quoted 32 lines
Quoted 30 lines · Mauro Carvalho Chehab
Em Wed, 09 Jan 2013 10:43:23 +0100
Oliver Schinagl <[email protected]> escreveu:Quoted 14 lines · Johannes Stezenbach
Quoted 6 lines · Oliver Schinagl
Quoted 5 lines · Jiri Slaby
Quoted 4 lines · Oliver Schinagl
Quoted 1 line
Unfortunatly, I have had zero replies.
Hmm, it's sad there is a silence in this thread from linux-media guys :/.
Quoted 7 lines
Quoted 2 lines
In their defense, they are very very busy people ;) chatter on this thread does bring it up however.
This is such a nice thing to say :-)
But it might be that Mauro thinks the dvb-apps maintainer should respond, but apparently there is no dvb-apps maintainer... Maybe you should ask Mauro directly to create an account for you to implement what you proposed.Quoted 8 lines
Mauro is CC'ed and I'd ask of course for this (I kinda did) but who decides what I suggested is a good idea? I personally obviously think it
is ;) and even more so if dvb-apps are unmaintained.I guess the question now becomes 'who okay's this change? Who says 'okay, lets do it this way. Once that is answered we can go from there ;)
If I understood it right, you want to split the scan files into a separate
git tree and maintain it, right?Quoted 8 lines
Quoted 4 lines
I'm ok with that.
Regards,
MauroAs a DVB maintainer, I am OK with this as well - It does indeed make sense to separate the c code sources from the regional frequency tables, and I'm sure we'll see much benefit from this change.
Done. I created a tree for Oliver to maintain it and an account for him. I also created a new tree with just the DVB table commits to:
http://git.linuxtv.org/dtv-scan-tables.git
Quoted 7 lines
Quoted 3 lines
I kept there both szap and scan files, although maybe it makes sense to drop the szap table (channels-conf dir). It also makes sense to drop the tables from the dvb-apps tree, to avoid duplicated stuff, and to avoid
Being one of the maintainers:
I will keep the tables in the dvb-apps tree for the time being.
That does not make sense at all -- why? Duplicated stuff always hurts.
Quoted 4 lines
Will decide to
drop the config files as needed from dvb-apps. It is necessary to keep a copy of the config files for development purposes, rather than pulling from different trees.
What development purposes, could you be more specific? You can still use git submodules if really needed. But as it stands I do not see a reason for that at all...
regards,
Signature · 1 line
js
Quoted 55 lines · Jiri Slaby
Quoted 54 lines · Manu Abraham
Quoted 52 lines · Mauro Carvalho Chehab
Em Wed, 9 Jan 2013 06:08:44 -0500
Michael Krufky <[email protected]> escreveu:Quoted 33 lines
Quoted 31 lines · Mauro Carvalho Chehab
Em Wed, 09 Jan 2013 10:43:23 +0100
Oliver Schinagl <[email protected]> escreveu:Quoted 19 lines · Johannes Stezenbach
Quoted 6 lines · Oliver Schinagl
Quoted 5 lines · Jiri Slaby
Quoted 4 lines · Oliver Schinagl
Quoted 1 line
Unfortunatly, I have had zero replies.
Hmm, it's sad there is a silence in this thread from linux-media guys :/.
Quoted 7 lines
Quoted 2 lines
In their defense, they are very very busy people ;) chatter on this thread does bring it up however.
This is such a nice thing to say :-)
But it might be that Mauro thinks the dvb-apps maintainer should respond, but apparently there is no dvb-apps maintainer... Maybe you should ask Mauro directly to create an account for you to implement what you proposed.Mauro is CC'ed and I'd ask of course for this (I kinda did) but who decides what I suggested is a good idea? I personally obviously think it
is ;) and even more so if dvb-apps are unmaintained.Quoted 4 lines
I guess the question now becomes 'who okay's this change? Who says 'okay, lets do it this way. Once that is answered we can go from there
;)If I understood it right, you want to split the scan files into a separate
git tree and maintain it, right?Quoted 8 lines
Quoted 4 lines
I'm ok with that.
Regards,
MauroAs a DVB maintainer, I am OK with this as well - It does indeed make sense to separate the c code sources from the regional frequency tables, and I'm sure we'll see much benefit from this change.
Done. I created a tree for Oliver to maintain it and an account for him. I also created a new tree with just the DVB table commits to:
http://git.linuxtv.org/dtv-scan-tables.gitI kept there both szap and scan files, although maybe it makes sense to drop the szap table (channels-conf dir). It also makes sense to drop the tables from the dvb-apps tree, to avoid duplicated stuff, and to avoid
Quoted 5 lines
Quoted 3 lines
Being one of the maintainers:
I will keep the tables in the dvb-apps tree for the time being.
That does not make sense at all -- why? Duplicated stuff always hurts.
The scan files and config files are very specific to dvb-apps, some applications
do rely on these config files. It doesn't really make sense to have split out config
files for these small applications.
Quoted 10 lines
Quoted 6 lines
Will decide to
drop the config files as needed from dvb-apps. It is necessary to keep a copy of the config files for development purposes, rather than pulling from
different trees.What development purposes, could you be more specific? You can still use git submodules if really needed. But as it stands I do not see a reason for that at all...
Did you think that the dvb-apps just came out of thin air ?
development of dvb-applications, implies eventually config files also will be updated as necessary. Having them in separate repositories makes such work harder for working.
while working with dvb-apps, it would make things saner if it is the same SCM, rather
than having different SCM's. So according to you, you want to make it still harder for someone to work with dvb-apps.
Manu
Quoted 93 lines · Manu Abraham
Quoted 55 lines · Jiri Slaby
Quoted 54 lines · Manu Abraham
Quoted 52 lines · Mauro Carvalho Chehab
Em Wed, 9 Jan 2013 06:08:44 -0500
Michael Krufky <[email protected]> escreveu:Quoted 33 lines
Quoted 31 lines · Mauro Carvalho Chehab
Em Wed, 09 Jan 2013 10:43:23 +0100
Oliver Schinagl <[email protected]> escreveu:Quoted 19 lines · Johannes Stezenbach
Quoted 6 lines · Oliver Schinagl
Quoted 5 lines · Jiri Slaby
Quoted 4 lines · Oliver Schinagl
Quoted 1 line
Unfortunatly, I have had zero replies.
Hmm, it's sad there is a silence in this thread from linux-media guys :/.
Quoted 7 lines
Quoted 2 lines
In their defense, they are very very busy people ;) chatter on this thread does bring it up however.
This is such a nice thing to say :-)
But it might be that Mauro thinks the dvb-apps maintainer should respond, but apparently there is no dvb-apps maintainer... Maybe you should ask Mauro directly to create an account for you to implement what you proposed.Mauro is CC'ed and I'd ask of course for this (I kinda did) but who decides what I suggested is a good idea? I personally obviously think it
is ;) and even more so if dvb-apps are unmaintained.Quoted 4 lines
I guess the question now becomes 'who okay's this change? Who says 'okay, lets do it this way. Once that is answered we can go from there
;)If I understood it right, you want to split the scan files into a separate
git tree and maintain it, right?Quoted 8 lines
Quoted 4 lines
I'm ok with that.
Regards,
MauroAs a DVB maintainer, I am OK with this as well - It does indeed make sense to separate the c code sources from the regional frequency tables, and I'm sure we'll see much benefit from this change.
Done. I created a tree for Oliver to maintain it and an account for him. I also created a new tree with just the DVB table commits to:
http://git.linuxtv.org/dtv-scan-tables.gitI kept there both szap and scan files, although maybe it makes sense to drop the szap table (channels-conf dir). It also makes sense to drop the tables from the dvb-apps tree, to avoid duplicated stuff, and to avoid
Quoted 5 lines
Quoted 3 lines
Being one of the maintainers:
I will keep the tables in the dvb-apps tree for the time being.
That does not make sense at all -- why? Duplicated stuff always hurts.
The scan files and config files are very specific to dvb-apps, some applications
do rely on these config files. It doesn't really make sense to have split out config
files for these small applications.Quoted 10 lines
Quoted 6 lines
Will decide to
drop the config files as needed from dvb-apps. It is necessary to keep a copy of the config files for development purposes, rather than pulling from
different trees.What development purposes, could you be more specific? You can still use git submodules if really needed. But as it stands I do not see a reason for that at all...
Did you think that the dvb-apps just came out of thin air ?
development of dvb-applications, implies eventually config files also will be updated as necessary. Having them in separate repositories makes such work harder for working.
while working with dvb-apps, it would make things saner if it is the same SCM, rather
than having different SCM's. So according to you, you want to make it still harder for someone to work with dvb-apps.
Quoted 1 line
Manu
Manu,
I see great value in separating the history of the data files from the code files. If you really think this is such a terrible task for a developer to have to pull from a second repository to fetch these data files, then I find no reason why we couldn't script it such that building the dvb-apps package would trigger the pull from the additional repository.
I think that's a fair compromise.
Meanwhile, your argument is for developers. Developers can handle pulling from a separated tree for data files who shouldn't be clouding the history of source code development, anyway. Developers are indeed used to dealing with multiple repositories, and if any developer isn't, then now is the time to get with the program!
I think this change is a great idea, and I would hope that we'd all agree on this, at least.
Best Regards,
Mike Krufky
Quoted 6 lines · Michael Krufky
I see great value in separating the history of the data files from the code files. If you really think this is such a terrible task for a developer to have to pull from a second repository to fetch these data files, then I find no reason why we couldn't script it such that building the dvb-apps package would trigger the pull from the additional repository.
(Or use submodules.)
Signature · 1 line
js
Quoted 105 lines · Michael Krufky
Quoted 99 lines · Manu Abraham
Quoted 60 lines · Jiri Slaby
Quoted 59 lines · Manu Abraham
Quoted 57 lines · Mauro Carvalho Chehab
Em Wed, 9 Jan 2013 06:08:44 -0500
Michael Krufky <[email protected]> escreveu:Quoted 35 lines
Quoted 33 lines · Mauro Carvalho Chehab
Em Wed, 09 Jan 2013 10:43:23 +0100
Oliver Schinagl <[email protected]> escreveu:Quoted 21 lines · Johannes Stezenbach
Quoted 6 lines · Oliver Schinagl
Quoted 5 lines · Jiri Slaby
Quoted 4 lines · Oliver Schinagl
Quoted 1 line
Unfortunatly, I have had zero replies.
Hmm, it's sad there is a silence in this thread from linux-media guys :/.
Quoted 8 lines
Quoted 3 lines
In their defense, they are very very busy people ;) chatter on this
thread does bring it up however.This is such a nice thing to say :-)
But it might be that Mauro thinks the dvb-apps maintainer should respond, but apparently there is no dvb-apps maintainer... Maybe you should ask Mauro directly to create an account for you to implement what you proposed.Mauro is CC'ed and I'd ask of course for this (I kinda did) but who decides what I suggested is a good idea? I personally obviously think
it
is ;) and even more so if dvb-apps are unmaintained.Quoted 4 lines
I guess the question now becomes 'who okay's this change? Who says 'okay, lets do it this way. Once that is answered we can go from there
;)If I understood it right, you want to split the scan files into a separate
git tree and maintain it, right?Quoted 8 lines
Quoted 4 lines
I'm ok with that.
Regards,
MauroAs a DVB maintainer, I am OK with this as well - It does indeed make sense to separate the c code sources from the regional frequency tables, and I'm sure we'll see much benefit from this change.
Done. I created a tree for Oliver to maintain it and an account for him.
I also created a new tree with just the DVB table commits to:
http://git.linuxtv.org/dtv-scan-tables.gitI kept there both szap and scan files, although maybe it makes sense to
drop the szap table (channels-conf dir). It also makes sense to drop the
tables from the dvb-apps tree, to avoid duplicated stuff, and to avoidQuoted 5 lines
Quoted 3 lines
Being one of the maintainers:
I will keep the tables in the dvb-apps tree for the time being.
That does not make sense at all -- why? Duplicated stuff always hurts.
The scan files and config files are very specific to dvb-apps, some applications
do rely on these config files. It doesn't really make sense to have split out config
files for these small applications.Quoted 11 lines
Quoted 7 lines
Will decide to
drop the config files as needed from dvb-apps. It is necessary to keep a
copy of the config files for development purposes, rather than pulling from
different trees.What development purposes, could you be more specific? You can still use git submodules if really needed. But as it stands I do not see a reason for that at all...
Did you think that the dvb-apps just came out of thin air ?
development of dvb-applications, implies eventually config files also will be updated as necessary. Having them in separate repositories makes such work harder for working.
while working with dvb-apps, it would make things saner if it is the same SCM, rather
than having different SCM's. So according to you, you want to make it still harder for someone to work with dvb-apps.Quoted 1 line
Manu
Manu,
Quoted 8 lines
I see great value in separating the history of the data files from the code files. If you really think this is such a terrible task for a developer to have to pull from a second repository to fetch these data files, then I find no reason why we couldn't script it such that building the dvb-apps package would trigger the pull from the additional repository.
I think that's a fair compromise.
As someone who has long been working with dvb-apps, I see no value
in this, but just pain altogether. For people who have never worked with it, they can say anything what they want, which makes no sense at all.
Quoted 5 lines
Meanwhile, your argument is for developers. Developers can handle pulling from a separated tree for data files who shouldn't be clouding the history of source code development, anyway. Developers are indeed used to dealing with multiple repositories, and if any developer isn't, then now is the time to get with the program!
It isn't that way. Users have to deal with 2 repositories as well. Anyway, the repository is not having that many developers to state that developers can handle all the burden. It is just but the reverse.
Manu
Quoted 113 lines · Manu Abraham
Quoted 112 lines · Michael Krufky
Quoted 99 lines · Manu Abraham
Quoted 60 lines · Jiri Slaby
Quoted 59 lines · Manu Abraham
Quoted 57 lines · Mauro Carvalho Chehab
Em Wed, 9 Jan 2013 06:08:44 -0500
Michael Krufky <[email protected]> escreveu:Quoted 35 lines
Quoted 33 lines · Mauro Carvalho Chehab
Em Wed, 09 Jan 2013 10:43:23 +0100
Oliver Schinagl <[email protected]> escreveu:Quoted 21 lines · Johannes Stezenbach
Quoted 6 lines · Oliver Schinagl
Quoted 5 lines · Jiri Slaby
Quoted 4 lines · Oliver Schinagl
Quoted 1 line
Unfortunatly, I have had zero replies.
Hmm, it's sad there is a silence in this thread from linux-media guys :/.
Quoted 8 lines
Quoted 3 lines
In their defense, they are very very busy people ;) chatter on this
thread does bring it up however.This is such a nice thing to say :-)
But it might be that Mauro thinks the dvb-apps maintainer should respond, but apparently there is no dvb-apps maintainer... Maybe you should ask Mauro directly to create an account for you to implement what you proposed.Mauro is CC'ed and I'd ask of course for this (I kinda did) but who decides what I suggested is a good idea? I personally obviously think
it
is ;) and even more so if dvb-apps are unmaintained.Quoted 4 lines
I guess the question now becomes 'who okay's this change? Who says 'okay, lets do it this way. Once that is answered we can go from there
;)If I understood it right, you want to split the scan files into a separate
git tree and maintain it, right?Quoted 8 lines
Quoted 4 lines
I'm ok with that.
Regards,
MauroAs a DVB maintainer, I am OK with this as well - It does indeed make sense to separate the c code sources from the regional frequency tables, and I'm sure we'll see much benefit from this change.
Done. I created a tree for Oliver to maintain it and an account for him.
I also created a new tree with just the DVB table commits to:
http://git.linuxtv.org/dtv-scan-tables.gitI kept there both szap and scan files, although maybe it makes sense to
drop the szap table (channels-conf dir). It also makes sense to drop the
tables from the dvb-apps tree, to avoid duplicated stuff, and to avoidQuoted 5 lines
Quoted 3 lines
Being one of the maintainers:
I will keep the tables in the dvb-apps tree for the time being.
That does not make sense at all -- why? Duplicated stuff always hurts.
The scan files and config files are very specific to dvb-apps, some applications
do rely on these config files. It doesn't really make sense to have split out config
files for these small applications.Quoted 11 lines
Quoted 7 lines
Will decide to
drop the config files as needed from dvb-apps. It is necessary to keep a
copy of the config files for development purposes, rather than pulling from
different trees.What development purposes, could you be more specific? You can still use git submodules if really needed. But as it stands I do not see a reason for that at all...
Did you think that the dvb-apps just came out of thin air ?
development of dvb-applications, implies eventually config files also will be updated as necessary. Having them in separate repositories makes such work harder for working.
while working with dvb-apps, it would make things saner if it is the same SCM, rather
than having different SCM's. So according to you, you want to make it still harder for someone to work with dvb-apps.Quoted 1 line
Manu
Manu,
I see great value in separating the history of the data files from the code files. If you really think this is such a terrible task for a developer to have to pull from a second repository to fetch these data files, then I find no reason why we couldn't script it such that building the dvb-apps package would trigger the pull from the additional repository.
Quoted 6 lines
Quoted 1 line
I think that's a fair compromise.
As someone who has long been working with dvb-apps, I see no value
in this, but just pain altogether. For people who have never worked with it, they can say anything what they want, which makes no sense at all.
Well there are a few apps that do use the initial scanfile tree, but do not use any of the dvb-apps.
(tvheadend, kaffeine appearantly, i'm guessing VDR and MythTV aswell?)
Quoted 9 lines
Quoted 7 lines
Meanwhile, your argument is for developers. Developers can handle pulling from a separated tree for data files who shouldn't be clouding the history of source code development, anyway. Developers are indeed used to dealing with multiple repositories, and if any developer isn't, then now is the time to get with the program!
Quoted 3 lines
It isn't that way. Users have to deal with 2 repositories as well. Anyway, the repository is not having that many developers to state that developers can handle all the burden. It is just but the reverse.
Well one of the biggest issues was, that the scanfiles where ill maintained and projects where working around those shortcommings.
The scanfiles are technically unrelated. They are data files, facts and can very logically live seperated :) Having commit messages pure for data files in a source tree just looks off.
They simply have become a seperate entity as people (not developers) depend on them. (Yes there is wscan of course).
Also, purely out of curiousity, how are the scanfiles used during development?
oliver
Quoted 7 lines
Manu
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 5 lines · Oliver Schinagl
Quoted 1 line
they can say anything what they want, which makes no sense at all.
Well there are a few apps that do use the initial scanfile tree, but do not use any of the dvb-apps.
(tvheadend, kaffeine appearantly, i'm guessing VDR and MythTV aswell?)
Only tvheadend and kaffeine AFAIK. VDR and MythTV have their own formats.
Quoted 14 lines
Quoted 9 lines
Quoted 7 lines
Meanwhile, your argument is for developers. Developers can handle pulling from a separated tree for data files who shouldn't be clouding the history of source code development, anyway. Developers are indeed used to dealing with multiple repositories, and if any developer isn't, then now is the time to get with the program!
Quoted 5 lines
It isn't that way. Users have to deal with 2 repositories as well. Anyway,
the repository is not having that many developers to state that developers
can handle all the burden. It is just but the reverse.
Quoted 6 lines
Well one of the biggest issues was, that the scanfiles where ill maintained and projects where working around those shortcommings.
The scanfiles are technically unrelated. They are data files, facts and can very logically live seperated :) Having commit messages pure for data files in a source tree just looks off.
The configuration files/data for dvb-apps.
Quoted 6 lines
They simply have become a seperate entity as people (not developers) depend on them. (Yes there is wscan of course).
Also, purely out of curiousity, how are the scanfiles used during development?
The scanfiles what you call them are the configuration files for dvb-apps, rather than purely data files.
Manu
Quoted 5 lines · Manu Abraham
Quoted 2 lines
Also, purely out of curiousity, how are the scanfiles used during development?
The scanfiles what you call them are the configuration files for dvb-apps, rather than purely data files.
But you cannot change their format, so what's the point? You can use them from a different directory or system ones...
Signature · 1 line
js
Quoted 10 lines · Jiri Slaby
Quoted 6 lines · Manu Abraham
Quoted 2 lines
Also, purely out of curiousity, how are the scanfiles used during development?
The scanfiles what you call them are the configuration files for dvb-apps,
rather than purely data files.But you cannot change their format, so what's the point? You can use them from a different directory or system ones...
The format can be definitely changed. There's no issue to it.
Manu
Quoted 1 line · Manu Abraham
The format can be definitely changed. There's no issue to it.
No you cannot. Applications depend on that, it's part of the dvb ABI. If you changed that, you would do the same mistake as Mauro let it flowing through his tree and it was pointed out by Linus in the link you sent...
Signature · 1 line
js
Quoted 6 lines · Jiri Slaby
Quoted 1 line · Manu Abraham
The format can be definitely changed. There's no issue to it.
No you cannot. Applications depend on that, it's part of the dvb ABI. If you changed that, you would do the same mistake as Mauro let it flowing through his tree and it was pointed out by Linus in the link you sent...
Id you provide an abstraction library, convert all applications to use that instead of the files, you can change them then. Not any time before.
Signature · 1 line
js
Quoted 11 lines · Jiri Slaby
Quoted 6 lines · Jiri Slaby
Quoted 1 line · Manu Abraham
The format can be definitely changed. There's no issue to it.
No you cannot. Applications depend on that, it's part of the dvb ABI. If you changed that, you would do the same mistake as Mauro let it flowing through his tree and it was pointed out by Linus in the link you sent...
Id you provide an abstraction library, convert all applications to use that instead of the files, you can change them then. Not any time before.
Well isn't the scan tables list a database of sorts? It contains the transponder settings for all public accessible transponders. Or should anyway.
The format, for now, suffices I'd think. Also, you already convert it sort of. You use dvbscan or whatever scan, to take those files and create channels.conf or what not from it (and search for extra transponders, but having _all_ transponders in the repository would be overkill though I think we do that for dvb-T?
So in a sense, it exists as that already :)
Quoted 6 lines · Jiri Slaby
Quoted 1 line · Manu Abraham
The format can be definitely changed. There's no issue to it.
No you cannot. Applications depend on that, it's part of the dvb ABI. If you changed that, you would do the same mistake as Mauro let it flowing through his tree and it was pointed out by Linus in the link you sent...
I understand what you are thinking, but that's not exactly about it. The format can simply be updated by adding newer params to it's end, thus not breaking any of the applications.
Manu
Quoted 11 lines · Manu Abraham
Quoted 6 lines · Jiri Slaby
Quoted 1 line · Manu Abraham
The format can be definitely changed. There's no issue to it.
No you cannot. Applications depend on that, it's part of the dvb ABI. If you changed that, you would do the same mistake as Mauro let it flowing through his tree and it was pointed out by Linus in the link you sent...
I understand what you are thinking, but that's not exactly about it. The format can simply be updated by adding newer params to it's end, thus not breaking any of the applications.
OK, but that still does not explain why it is requisite to have the data along with the sources. There is no problem in updating both the files and scandata separately, because it has to be compatible.
Also I'm not sure whether adding a column at the end wouldn't break the apps.
Signature · 1 line
js
Quoted 15 lines · Jiri Slaby
Quoted 8 lines · Manu Abraham
Quoted 6 lines · Jiri Slaby
Quoted 1 line · Manu Abraham
The format can be definitely changed. There's no issue to it.
No you cannot. Applications depend on that, it's part of the dvb ABI. If you changed that, you would do the same mistake as Mauro let it flowing through his tree and it was pointed out by Linus in the link you sent...
Quoted 5 lines
I understand what you are thinking, but that's not exactly about it. The format
can simply be updated by adding newer params to it's end, thus not breaking
any of the applications.
Quoted 4 lines
OK, but that still does not explain why it is requisite to have the data along with the sources. There is no problem in updating both the files and scandata separately, because it has to be compatible.
scenario1:
clone tree 1
make changes
update tree 1
scenario2:
clone tree 1
make changes
update tree 1
clone tree 2
make changes
update tree 2
It seems to me that scenario 2 is twice the work, to keep it updated. :-) Simply no reason to do double the work.
Quoted 2 lines
Also I'm not sure whether adding a column at the end wouldn't break the apps.
Don't worry. We have already done that in the past.
Manu
Quoted 7 lines · Jiri Slaby
Quoted 1 line · Manu Abraham
The format can be definitely changed. There's no issue to it.
No you cannot. Applications depend on that, it's part of the dvb ABI. If you changed that, you would do the same mistake as Mauro let it flowing through his tree and it was pointed out by Linus in the link you sent...
Actually, there's plenty of apps etc that depend on it. I know some distro's install it into /usr/share/dvb for all to use. I think actually only a very small handfull use their own scanfiles. Very small handfull I belive ;)
Quoted 4 lines · Oliver Schinagl
Actually, there's plenty of apps etc that depend on it. I know some distro's install it into
/usr/share/dvbfor all to use. I think actually only a very small handfull use their own scanfiles. Very small handfull I belive ;)
Indeed. I have just gone to file an Intent To Package bug for the dtv-scan-tables package in Debian, but I noticed that the COPYING and README files were not split out from the dvb-apps tree.
Logically it would follow that dtv-scan-tables is also licenced under LGPL, the same as dvb-apps, but this needs to be stated explicitly. This is especially true for distributions which be redistributing dtv-scan-tables.
Thanks,
Jon
Legallity of dtv-scan-tables Was: [RFC] Initial scan files troubles and brainstorming
Quoted 8 lines · Jonathan McCrohan
Quoted 4 lines · Oliver Schinagl
Actually, there's plenty of apps etc that depend on it. I know some distro's install it into
/usr/share/dvbfor all to use. I think actually only a very small handfull use their own scanfiles. Very small handfull I belive ;)Indeed. I have just gone to file an Intent To Package bug for the dtv-scan-tables package in Debian, but I noticed that the COPYING and README files were not split out from the dvb-apps tree.
If some have any pointers in what would be logical in the readme, i'll whip one up this afternoon.
but copying is an interesting point.
Quoted 5 lines
Logically it would follow that dtv-scan-tables is also licenced under LGPL, the same as dvb-apps, but this needs to be stated explicitly. This is especially true for distributions which be redistributing dtv-scan-tables.
I don't think it is that logical actually. Remember the ntpd fiasco a few months back? Where some company claimed they had copyright on factual data?
This is as far as I can tell, factual data. A Satellite or Antenna is configured to broadcast in a certain way, the scan tables are a collection of this data. They get to us from volunteers who either scan for them or find 'official' docs from the broadcaster and re-arrange it to something useful to us.....
So who owns this data? Can it be licensed as GPL? Falls it under the Public Domain by default?
Personally, I think that the copyright license applied to the actual source code, but not the scan tables.
Quoted 3 lines
Thanks,
Jon
Oliver
Em Fri, 11 Jan 2013 01:12:33 +0000
Jonathan McCrohan <[email protected]> escreveu:
Quoted 6 lines · Oliver Schinagl
Quoted 4 lines
Actually, there's plenty of apps etc that depend on it. I know some distro's install it into
/usr/share/dvbfor all to use. I think actually only a very small handfull use their own scanfiles. Very small handfull I belive ;)
Quoted 8 lines
Indeed. I have just gone to file an Intent To Package bug for the dtv-scan-tables package in Debian, but I noticed that the COPYING and README files were not split out from the dvb-apps tree.
Logically it would follow that dtv-scan-tables is also licenced under LGPL, the same as dvb-apps, but this needs to be stated explicitly. This is especially true for distributions which be redistributing dtv-scan-tables.
As this is currently a copy of the dvb-apps, and the other patches added there are sent meant to be merged at dvb-apps, the license that applies on it should be inherited.
That's said, this is just database entries where the values were obtained from a public service. Anyone else with access to the same transponders/carriers would be obtaining the very same data. So, I don't think that copyright law applies here. IANAL, but it sounds to me that such info would be public domain.
Yet, to avoid legal issues, I suggest to copy the COPYING from the dvb-apps tree. Also, sooner or later a Makefile will likely be added there, and maybe some ancillary scripts. So, it makes sense to state the license there anyway.
Regards,
Mauro
Quoted 5 lines · Mauro Carvalho Chehab
That's said, this is just database entries where the values were obtained from a public service. Anyone else with access to the same transponders/carriers would be obtaining the very same data. So, I don't think that copyright law applies here. IANAL, but it sounds to me that such info would be public domain.
Please be aware that in at least the EU database compilations _can_ be copyrighted. It makes life a lot simpler for distributions if you just pretend that it can be copyrighted and apply a license. If you want something approaching public domain, the BSD license is an obvious choice. Going with the LGPL as you propose later in the email is perfectly fine too.
/Benny
Em Fri, 11 Jan 2013 15:10:38 +0100
Benny Amorsen <[email protected]> escreveu:
Quoted 11 lines
Quoted 5 lines · Mauro Carvalho Chehab
That's said, this is just database entries where the values were obtained from a public service. Anyone else with access to the same transponders/carriers would be obtaining the very same data. So, I don't think that copyright law applies here. IANAL, but it sounds to me that such info would be public domain.
Please be aware that in at least the EU database compilations _can_ be copyrighted. It makes life a lot simpler for distributions if you just pretend that it can be copyrighted and apply a license.
Yes. Better safe than sorry.
Quoted 4 lines
If you want
something approaching public domain, the BSD license is an obvious choice. Going with the LGPL as you propose later in the email is perfectly fine too.
Changing to BSD could be a problem, as re-licensing would require an ack from the original contributors, except if the license is a compatible one. Collecting everyone's ack on such change could be painful, and for no good reason.
So, to make it simpler, I would just use the LGPL.
Regards,
Mauro
Quoted 26 lines · Mauro Carvalho Chehab
Em Fri, 11 Jan 2013 01:12:33 +0000
Jonathan McCrohan <[email protected]> escreveu:Quoted 5 lines · Oliver Schinagl
Quoted 4 lines
Actually, there's plenty of apps etc that depend on it. I know some distro's install it into
/usr/share/dvbfor all to use. I think actually only a very small handfull use their own scanfiles. Very small handfull I belive ;)Quoted 8 lines
Indeed. I have just gone to file an Intent To Package bug for the dtv-scan-tables package in Debian, but I noticed that the COPYING and README files were not split out from the dvb-apps tree.
Logically it would follow that dtv-scan-tables is also licenced under LGPL, the same as dvb-apps, but this needs to be stated explicitly. This is especially true for distributions which be redistributing dtv-scan-tables.
As this is currently a copy of the dvb-apps, and the other patches added there are sent meant to be merged at dvb-apps, the license that applies on it should be inherited.
That's said, this is just database entries where the values were obtained from a public service. Anyone else with access to the same transponders/carriers would be obtaining the very same data. So, I don't think that copyright law applies here. IANAL, but it sounds to me that such info would be public domain.
Quoted 4 lines
Yet, to avoid legal issues, I suggest to copy the COPYING from the dvb-apps tree. Also, sooner or later a
Makefilewill likely be added there, and maybe some ancillary scripts. So, it makes sense to state the license there anyway.
License has been merged from dvb-apps (keeping history) and pushed to the repo.
Quoted 2 lines
Regards,
Mauro
Em Fri, 11 Jan 2013 01:55:34 +0530
Manu Abraham <[email protected]> escreveu:
Quoted 8 lines · Oliver Schinagl
Quoted 5 lines
Quoted 1 line
they can say anything what they want, which makes no sense at all.
Well there are a few apps that do use the initial scanfile tree, but do not use any of the dvb-apps.
(tvheadend, kaffeine appearantly, i'm guessing VDR and MythTV aswell?)
Only tvheadend and kaffeine AFAIK. VDR and MythTV have their own formats.
Both mplayer and vlc work with the channels-conf files.
Cheers,
Mauro
Quoted 5 lines · Mauro Carvalho Chehab
Em Fri, 11 Jan 2013 01:55:34 +0530
Manu Abraham <[email protected]> escreveu:Quoted 2 lines · Oliver Schinagl
Quoted 1 line
Quoted 1 line
they can say anything what they want, which makes no sense at all.
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Well there are a few apps that do use the initial scanfile tree, but do not use any of the dvb-apps.
(tvheadend, kaffeine appearantly, i'm guessing VDR and MythTV aswell?)
Only tvheadend and kaffeine AFAIK. VDR and MythTV have their own formats.
Both mplayer and vlc work with the channels-conf files.
True. they depend upon the output from dvbscan. So when scan changes format, they will also need to "update formats to acquire new functionality", else they will be stuck with old functionality.
Manu
Quoted 8 lines · Oliver Schinagl
Quoted 5 lines · Manu Abraham
It isn't that way. Users have to deal with 2 repositories as well. Anyway,
the repository is not having that many developers to state that developers
can handle all the burden. It is just but the reverse.Well one of the biggest issues was, that the scanfiles where ill maintained and projects where working around those shortcommings.
I do see that Christoph hasn't been around lately. I would appreciate it as well, if you would maintain the files within the dvb-apps repository itself.
Manu
Quoted 5 lines · Manu Abraham
The scan files and config files are very specific to dvb-apps, some applications
do rely on these config files. It doesn't really make sense to have split out config
files for these small applications.
I don't care where they are, really. However I'm strongly against duplicating them. Feel free to remove the newly created repository, I'll be fine with that.
Quoted 2 lines
So according to you, you want to make it
still harder for someone to work with dvb-apps.
I wasn't the one to suggest a separate directory for the data, there is no point in blaming me...
Signature · 1 line
js
Quoted 10 lines · Jiri Slaby
Quoted 5 lines · Manu Abraham
The scan files and config files are very specific to dvb-apps, some applications
do rely on these config files. It doesn't really make sense to have split out config
files for these small applications.I don't care where they are, really. However I'm strongly against duplicating them. Feel free to remove the newly created repository, I'll be fine with that.
I haven't duplicated anything at all. It is Mauro who has duplicated stuff, by creating a new tree altogether.
if you need the scan files to be properly maintained then you need to handle it in the same repository altogether. Not by separating out the configuration files of a few applications.
Manu
Quoted 8 lines · Manu Abraham
Quoted 7 lines · Jiri Slaby
Quoted 5 lines · Manu Abraham
The scan files and config files are very specific to dvb-apps, some applications
do rely on these config files. It doesn't really make sense to have split out config
files for these small applications.
Quoted 6 lines
Quoted 3 lines
I don't care where they are, really. However I'm strongly against duplicating them. Feel free to remove the newly created repository, I'll be fine with that.
I haven't duplicated anything at all. It is Mauro who has duplicated stuff, by creating a new tree altogether.
I didn't accuse you. This was a general comment to everybody. Whatever the consensus is at the end, do not duplicate the data.
Quoted 3 lines
if you need the scan files to be properly maintained then you need to handle it in the same repository altogether. Not by separating out the configuration files of a few applications.
That's up to you guys to decide. I don't mind either option.
Signature · 1 line
js
Quoted 13 lines · Jiri Slaby
Quoted 12 lines · Manu Abraham
Quoted 10 lines · Jiri Slaby
Quoted 5 lines · Manu Abraham
The scan files and config files are very specific to dvb-apps, some applications
do rely on these config files. It doesn't really make sense to have split out config
files for these small applications.I don't care where they are, really. However I'm strongly against duplicating them. Feel free to remove the newly created repository, I'll be fine with that.
Quoted 6 lines
Quoted 3 lines
I haven't duplicated anything at all. It is Mauro who has duplicated stuff,
by creating a new tree altogether.I didn't accuse you. This was a general comment to everybody. Whatever the consensus is at the end, do not duplicate the data.
Eventually what will happen is that, as applications do get developed, the config files which are alongwith the applications will have proper compatibility with the applications while, the split out config files will be in a different state, providing nothing but pain for everyone.
Manu
Em Fri, 11 Jan 2013 00:38:18 +0530
Manu Abraham <[email protected]> escreveu:
Quoted 8 lines · Jiri Slaby
Quoted 7 lines · Manu Abraham
Quoted 5 lines
The scan files and config files are very specific to dvb-apps, some applications
do rely on these config files. It doesn't really make sense to have split out config
files for these small applications.
Quoted 6 lines
Quoted 3 lines
I don't care where they are, really. However I'm strongly against duplicating them. Feel free to remove the newly created repository, I'll be fine with that.
I haven't duplicated anything at all. It is Mauro who has duplicated stuff, by creating a new tree altogether.
I only did it by request, and after having some consensus at the ML, and after people explicitly asking me to do that.
I even tried to not express my opinion to anybody. But it seems I'm forced by you to give it. So, let it be.
The last patches from you there were 11 months ago, and didn't bring any new functionality there... they are just indentation fixes:
http://www.linuxtv.org/hg/dvb-apps/
The last one with a new functionality seems to be this one, 15 months ago:
http://www.linuxtv.org/hg/dvb-apps/rev/d4e8bf5658ce
Also, people find a very bad time when they submit any fixes for the driver you wrote, as you doesn't seem to have enough time to review their patches.
So, I suspect that you're a very very busy person, with almost no time to maintain your previous work. If something has changed, and you're now finding more time, I'd pleased if you could review the patches that are there for a long time (there is one from 2011 that it is a rebase of an even older patch) before re-doing Oliver's scanfile updates at dvb-tools:
http://www.spinics.net/lists/linux-media/msg58283.html
Considering that nobody is having much time for the dvb-apps tree nowadays, I really think that it would be great to get someone with more time to maintain those files, as otherwise the update scan files may be on the limbo for a long time, and releasing us to have more time with development.
As proposed by Oliver, it seemed to be a good idea to have it on a separate tree, as those scan files are actually independent of the dvb-apps, and can be used by other applications.
That's why I welcomed Oliver's initiative to maintain it, and I wish him a good work with that.
Quoted 4 lines
Eventually what will happen is that, as applications do get developed, the config files which are alongwith the applications will have proper compatibility with the applications while, the split out config files will be in a different state, providing nothing but pain for everyone.
The format of those files can't be changed without breaking other existing applications that relies on its format, like mplayer, vlc, etc.
It could make sense, though, to convert them in the future to a more generic format that would be delivery-system independent and that could easily be converted into all application-specific formats, and add there some format-change tool that would dynamically generate the files at vdr, dvb-apps, kaffeine... format.
By having it on a separate tree, with its own maintainer, Oliver can focus on it, without needing to be bothered with maintaining the dvb-apps.
So, it makes all sense for me to have it maintained in separate.
That's said, there's no problem on having those files maintained on two or more trees. Actually, there are already dozens of forks of it, as each distribution has its own dvb-apps fork, some outdated and eventually some with their own scan files there.
So, if no agreement is reached, I would just keep it as is for a while and review it maybe an year later.
Regards,
Mauro
Quoted 16 lines · Mauro Carvalho Chehab
Em Fri, 11 Jan 2013 00:38:18 +0530
Manu Abraham <[email protected]> escreveu:Quoted 13 lines · Jiri Slaby
Quoted 11 lines · Manu Abraham
Quoted 5 lines
The scan files and config files are very specific to dvb-apps, some applications
do rely on these config files. It doesn't really make sense to have split out config
files for these small applications.I don't care where they are, really. However I'm strongly against duplicating them. Feel free to remove the newly created repository, I'll
be fine with that.
Quoted 7 lines
Quoted 3 lines
I haven't duplicated anything at all. It is Mauro who has duplicated stuff,
by creating a new tree altogether.I only did it by request, and after having some consensus at the ML, and after people explicitly asking me to do that.
Having consensus implies that the people involved with it are in that loop, rather than having a superfluous one with no one of it in that loop.
Manu
Quoted 23 lines · Mauro Carvalho Chehab
Em Fri, 11 Jan 2013 00:38:18 +0530
Manu Abraham <[email protected]> escreveu:Quoted 8 lines · Jiri Slaby
Quoted 7 lines · Manu Abraham
Quoted 5 lines
The scan files and config files are very specific to dvb-apps, some applications
do rely on these config files. It doesn't really make sense to have split out config
files for these small applications.Quoted 8 lines
Quoted 4 lines
I don't care where they are, really. However I'm strongly against duplicating them. Feel free to remove the newly created repository, I'll
be fine with that.I haven't duplicated anything at all. It is Mauro who has duplicated stuff,
by creating a new tree altogether.I only did it by request, and after having some consensus at the ML, and after people explicitly asking me to do that.
Quoted 6 lines
I even tried to not express my opinion to anybody. But it seems I'm forced by you to give it. So, let it be.
The last patches from you there were 11 months ago, and didn't bring any new functionality there... they are just indentation fixes:
http://www.linuxtv.org/hg/dvb-apps/
The way you do things, it all ends up like this.
https://lkml.org/lkml/2012/12/23/75
Manu
Quoted 27 lines · Manu Abraham
Quoted 26 lines · Mauro Carvalho Chehab
Em Fri, 11 Jan 2013 00:38:18 +0530
Manu Abraham <[email protected]> escreveu:Quoted 8 lines · Jiri Slaby
Quoted 7 lines · Manu Abraham
Quoted 5 lines
The scan files and config files are very specific to dvb-apps, some applications
do rely on these config files. It doesn't really make sense to have split out config
files for these small applications.Quoted 8 lines
Quoted 4 lines
I don't care where they are, really. However I'm strongly against duplicating them. Feel free to remove the newly created repository, I'll
be fine with that.I haven't duplicated anything at all. It is Mauro who has duplicated stuff,
by creating a new tree altogether.I only did it by request, and after having some consensus at the ML, and after people explicitly asking me to do that.
I even tried to not express my opinion to anybody. But it seems I'm forced by you to give it. So, let it be.
Quoted 8 lines
Quoted 3 lines
The last patches from you there were 11 months ago, and didn't bring any new functionality there... they are just indentation fixes:
http://www.linuxtv.org/hg/dvb-apps/The way you do things, it all ends up like this.
That's just mean and below the belt.
Anyway, I've brought this issue up on the 18th of oktober 2012 on this mailing list. I had zero replies until early december. Jonathan commented a little and said it was a good idea.
Also a few comments about how their patches to scanfiles (data files, facts) where ignored for weeks to an end.
Mauro didn't get involved to have everybody that is a maintainer etc get a good chance to respond.
The only thing that came from this, is that someone actually stopped maintaining it.
Then after everything actually was done (for the better imo), you come in and say it's a bad thing, but dont' really tell us why. Other than it makes development hard for you, which nobody really agree's to with.
Anyway, fighting about it won't help anyone, but a good argument as to which procedure is better is good for everyone :)
Oliver
Quoted 8 lines
Manu
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 36 lines · Oliver Schinagl
Quoted 27 lines · Manu Abraham
Quoted 26 lines · Mauro Carvalho Chehab
Em Fri, 11 Jan 2013 00:38:18 +0530
Manu Abraham <[email protected]> escreveu:Quoted 8 lines · Jiri Slaby
Quoted 7 lines · Manu Abraham
Quoted 5 lines
The scan files and config files are very specific to dvb-apps, some applications
do rely on these config files. It doesn't really make sense to have split out config
files for these small applications.Quoted 8 lines
Quoted 4 lines
I don't care where they are, really. However I'm strongly against duplicating them. Feel free to remove the newly created repository, I'll
be fine with that.I haven't duplicated anything at all. It is Mauro who has duplicated stuff,
by creating a new tree altogether.I only did it by request, and after having some consensus at the ML, and after people explicitly asking me to do that.
I even tried to not express my opinion to anybody. But it seems I'm forced by you to give it. So, let it be.
Quoted 8 lines
Quoted 3 lines
The last patches from you there were 11 months ago, and didn't bring any new functionality there... they are just indentation fixes:
http://www.linuxtv.org/hg/dvb-apps/The way you do things, it all ends up like this.
Quoted 9 lines
That's just mean and below the belt.
Anyway, I've brought this issue up on the 18th of oktober 2012 on this mailing list. I had zero replies until early december. Jonathan commented a little and said it was a good idea.
Also a few comments about how their patches to scanfiles (data files, facts) where ignored for weeks to an end.
There was someone who was actively maintaining the config files. One cannot simply state something different unless that person has to say something. In this case as soon as Christoph talked about his stand, I did express my opinion as well.
Quoted 3 lines
Mauro didn't get involved to have everybody that is a maintainer etc get a good chance to respond.
Mauro doesn't do anything wrt dvb-apps. I don't understand, what you are trying to state here.
Quoted 6 lines
The only thing that came from this, is that someone actually stopped maintaining it.
Then after everything actually was done (for the better imo), you come in and say it's a bad thing, but dont' really tell us why. Other than it makes development hard for you, which nobody really agree's to with.
At least you should have the courtesy to talk about it with the people who are/were working with it, rather than the people who have no connection to it.
I don't want to let go of the efforts that you would like to put into, and hence stated that it would be appreciated if you would maintain the config files within the dvb-apps tree.
Just like how you think it is bad for the applications to carry it's own configuration files, I think that it is better for any application to carry it's own configuration files.
Manu
Em Thu, 10 Jan 2013 21:51:29 +0100
Oliver Schinagl <[email protected]> escreveu:
Quoted 1 line
Anyway, fighting about it won't help anyone
Agreed. From my side, don't expect further comments. That's hopefully my last email on this thread.
Oliver,
You owns your time. So, it is really your call.
Quoted 1 line
From my side, I appreciate your efforts on keep maintaining it.
I don't really care if this is done as a separate tree and/or together with dvb-apps, although, except for the scan files, the dvb-apps seem pretty much orphaned for a long time. So, among other reasons, IMHO it is better to keep it forked.
In any case, reimporting the files from an external tree is easy. It is equally easy to add a script at dvb-apps and on other applications that would take a tarball of it and copy the files there. We do that approach on v4l-utils, in order to sync it with kernel headers and kernel IR scancode tables, as we do need new headers there during development, and users do need the very latest IR scancode tables.
If you decide to keep it in separate, I recommend you to add there some version schema to make easier for distributions that may want to add a package there, for them to track when this gets updated.
Also, just like what we do with media-build's "todaytar" target, it may also make some sense to have an script running at linuxtv.org that would create daily tarballs when a new commit is merged there, or when a new tag is added. That would help to have scripts at applications to sync with the latest files.
If you decide to either drop the tree or to add such tarball script at the server, please ping me.
Signature · 2 lines
Cheers, Mauro
Quoted 11 lines · Mauro Carvalho Chehab
Em Thu, 10 Jan 2013 21:51:29 +0100
Oliver Schinagl <[email protected]> escreveu:Quoted 1 line
Anyway, fighting about it won't help anyone
Agreed. From my side, don't expect further comments. That's hopefully my last email on this thread.
Oliver,
You owns your time. So, it is really your call.
Well I did write the initial plea for the seperation. :)
Quoted 2 lines
From my side, I appreciate your efforts on keep maintaining it.
I will do my very best for as long as time permits. I find it personally important that my scanfiles are updated as quickly as possibly and so will also update others as quickly as I can.
Quoted 5 lines
I don't really care if this is done as a separate tree and/or together with dvb-apps, although, except for the scan files, the dvb-apps seem pretty much orphaned for a long time. So, among other reasons, IMHO it is better to keep it forked.
I still think it does make sense for reasons I posted 3 months ago.
Quoted 7 lines
In any case, reimporting the files from an external tree is easy. It is equally easy to add a script at dvb-apps and on other applications that would take a tarball of it and copy the files there. We do that approach on v4l-utils, in order to sync it with kernel headers and kernel IR scancode tables, as we do need new headers there during development, and users do need the very latest IR scancode tables.
If dvb-apps depends on the scanfiles that horribly specifically, then a script to copy over the latest release would be best.
Quoted 4 lines
If you decide to keep it in separate, I recommend you to add there some version schema to make easier for distributions that may want to add a package there, for them to track when this gets updated.
Personally, I'd say date based would be best. After each commit a new tarball should be created. Since it's not 'code' that changes, but factual data, any change warrants a release. So dtv-scan-files-2013011.tar.bz2/xz and is common?
if for any reason a second release is needed on the same date ... too bad :p it's extremly unlikly anyway and can be done the next day's date. Or add an index after the date.
Quoted 6 lines
Also, just like what we do with media-build's "todaytar" target, it may also make some sense to have an script running at linuxtv.org that would create daily tarballs when a new commit is merged there, or when a new tag is added. That would help to have scripts at applications to sync with the latest files.
Well you want to release every commit really, as above stated a commit indicates a change in a transponder. Users of that transponder want to be able to use it asap.
Quoted 3 lines
If you decide to either drop the tree or to add such tarball script at the server, please ping me.
Ping :p
Quoted 1 line
Em Thu, 10 Jan 2013 23:57:42 +0100
Oliver Schinagl <[email protected]> escreveu:
Quoted 40 lines · Mauro Carvalho Chehab
Quoted 11 lines
Em Thu, 10 Jan 2013 21:51:29 +0100
Oliver Schinagl <[email protected]> escreveu:Quoted 1 line
Anyway, fighting about it won't help anyone
Agreed. From my side, don't expect further comments. That's hopefully my last email on this thread.
Oliver,
You owns your time. So, it is really your call.
Well I did write the initial plea for the seperation. :)
Quoted 2 lines
From my side, I appreciate your efforts on keep maintaining it.
I will do my very best for as long as time permits. I find it personally important that my scanfiles are updated as quickly as possibly and so will also update others as quickly as I can.
Quoted 5 lines
I don't really care if this is done as a separate tree and/or together with dvb-apps, although, except for the scan files, the dvb-apps seem pretty much orphaned for a long time. So, among other reasons, IMHO it is better to keep it forked.
I still think it does make sense for reasons I posted 3 months ago.
Quoted 7 lines
In any case, reimporting the files from an external tree is easy. It is equally easy to add a script at dvb-apps and on other applications that would take a tarball of it and copy the files there. We do that approach on v4l-utils, in order to sync it with kernel headers and kernel IR scancode tables, as we do need new headers there during development, and users do need the very latest IR scancode tables.
If dvb-apps depends on the scanfiles that horribly specifically, then a script to copy over the latest release would be best.
Quoted 4 lines
If you decide to keep it in separate, I recommend you to add there some version schema to make easier for distributions that may want to add a package there, for them to track when this gets updated.
Quoted 8 lines
Personally, I'd say date based would be best. After each commit a new tarball should be created. Since it's not 'code' that changes, but factual data, any change warrants a release. So dtv-scan-files-2013011.tar.bz2/xz and is common?
if for any reason a second release is needed on the same date ... too bad :p it's extremly unlikly anyway and can be done the next day's date. Or add an index after the date.
To re-use the existing script, you'll need to create a Makefile target to generate such tar. The script runs once during the night, comparing the previous commit hash with the current one. If different, it creates a new tarball.
The Makefile there could be as simple as:
tgz:
git archive --format tgz HEAD >dtv-scan-files-`date +"%Y%m%d.%H:%M"`.tar.gz
The above is for tar.gz - I don't object if you want to use a different compression provided that there are just one format. You may need to play a little bit with git config files, to add support for xz and bz2.
Quoted 6 lines
Quoted 6 lines
Also, just like what we do with media-build's "todaytar" target, it may also make some sense to have an script running at linuxtv.org that would create daily tarballs when a new commit is merged there, or when a new tag is added. That would help to have scripts at applications to sync with the latest files.
Quoted 9 lines
Well you want to release every commit really, as above stated a commit indicates a change in a transponder. Users of that transponder want to be able to use it asap.
Quoted 3 lines
If you decide to either drop the tree or to add such tarball script at the server, please ping me.
Ping :p
Quoted 1 line
Please add a Makefile there and ping me, and I'll adapt the existing script to also run on this project.
Signature · 2 lines
Cheers, Mauro
Quoted 2 lines · Mauro Carvalho Chehab
tgz:
git archive --format tgz HEAD >dtv-scan-files-`date +"%Y%m%d.%H:%M"`.tar.gz
Better to use the top commit date:
git log -n1 --date=short --pretty=format:%ad
You won't generate a snapshot every day with the same contents then.
or %ad-g%p if you want also a short commit id in there.
Signature · 1 line
js
daily tarballs of dtv-scan-tables - was Re: [RFC] Initial scan files troubles and brainstorming
In reply to Mauro Carvalho ChehabHi Oliver,
Em Fri, 11 Jan 2013 10:39:37 -0200
Mauro Carvalho Chehab <[email protected]> escreveu:
Quoted 3 lines
Em Thu, 10 Jan 2013 23:57:42 +0100
Oliver Schinagl <[email protected]> escreveu:
...
Quoted 14 lines
Quoted 8 lines
Personally, I'd say date based would be best. After each commit a new tarball should be created. Since it's not 'code' that changes, but factual data, any change warrants a release. So dtv-scan-files-2013011.tar.bz2/xz and is common?
if for any reason a second release is needed on the same date ... too bad :p it's extremly unlikly anyway and can be done the next day's date. Or add an index after the date.
To re-use the existing script, you'll need to create a
Makefiletarget to generate such tar. The script runs once during the night, comparing the previous commit hash with the current one. If different, it creates a new tarball.
Quoted 8 lines
The
Makefilethere could be as simple as:tgz:
git archive --format tgz HEAD >dtv-scan-files-`date +"%Y%m%d.%H:%M"`.tar.gzThe above is for tar.gz - I don't object if you want to use a different compression provided that there are just one format. You may need to play a little bit with git config files, to add support for xz and bz2.
I found some time today to implement a script to generate the tarball files for dtv-scan-tables at the LinuxTV server.
The script runs daily, checking if there was any new changeset at the repository. If it finds a new changeset there, it will take the date and the changeset of the latest commit at the tree and them as part of the tarball name, adding them to the following directory:
http://linuxtv.org/downloads/dtv-scan-tables/
The script will also create an hyperlink of the latest tarball at:
dtv-scan-tables-LATEST.tar.bz2
Every time a new file is added there, it will also update the md5sum file, that could be used by someone to check the downloads.
Regards,
Mauro
Re: daily tarballs of dtv-scan-tables - was Re: [RFC] Initial scan files troubles and brainstorming
Quoted 40 lines · Mauro Carvalho Chehab
Hi Oliver,
Em Fri, 11 Jan 2013 10:39:37 -0200
Mauro Carvalho Chehab <[email protected]> escreveu:Quoted 3 lines
Em Thu, 10 Jan 2013 23:57:42 +0100
Oliver Schinagl <[email protected]> escreveu:...
Quoted 14 lines
Quoted 8 lines
Personally, I'd say date based would be best. After each commit a new tarball should be created. Since it's not 'code' that changes, but factual data, any change warrants a release. So dtv-scan-files-2013011.tar.bz2/xz and is common?
if for any reason a second release is needed on the same date ... too bad :p it's extremly unlikly anyway and can be done the next day's date. Or add an index after the date.
To re-use the existing script, you'll need to create a
Makefiletarget to generate such tar. The script runs once during the night, comparing the previous commit hash with the current one. If different, it creates a new tarball.Quoted 8 lines
The
Makefilethere could be as simple as:tgz:
git archive --format tgz HEAD >dtv-scan-files-`date +"%Y%m%d.%H:%M"`.tar.gzThe above is for tar.gz - I don't object if you want to use a different compression provided that there are just one format. You may need to play a little bit with git config files, to add support for xz and bz2.
I found some time today to implement a script to generate the tarball files for dtv-scan-tables at the LinuxTV server.
The script runs daily, checking if there was any new changeset at the repository. If it finds a new changeset there, it will take the date and the changeset of the latest commit at the tree and them as part of the tarball name, adding them to the following directory:
Quoted 4 lines
http://linuxtv.org/downloads/dtv-scan-tables/
The script will also create an hyperlink of the latest tarball at:
dtv-scan-tables-LATEST.tar.bz2
Is there any easy way for me to see the script? Just so I can learn from it.
Quoted 3 lines
Every time a new file is added there, it will also update the md5sum file, that could be used by someone to check the downloads.
That is very cool and very much thank you.
I'll immediately publicly admit I have been slacking here. I should have picked up on that and done it. I've been dragged away and been busy with http://linux-sunxi.org.
Anyway Thank you for picking that up. The dtv tree should be up to date however, all messages I saw passing the mailing lists have been pushed.
I will (slowly) inform others that are interested (package maintainers) and see how it goes.
Thanks again Mauro!
Quoted 4 lines
Regards,
Mauro
Oliver
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Mauro,
Quoted 9 lines · Mauro Carvalho Chehab
Hi Oliver,
Em Wed, 09 Jan 2013 13:24:13 +0100
Oliver Schinagl <[email protected]> escreveu:Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
If I understood it right, you want to split the scan files into a separate git tree and maintain it, right?
I'm ok with that.
<snip>
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
I also migrated the dvb-apps changesets with the tables to: http://git.linuxtv.org/dtv-scan-tables.git Feel free to maintain it.
Thank you, this will be the new name for it (I will locally rename it) and try my bestest to maintain it :)
I will put a mention on the wiki 'how to submit scanfiles' (via the ML with tags in subject/pull requests) so people have a clear way how to submit them and I have a clear way to find them.
Quoted 4 lines
You should also have access to the dvb-apps hg tree. IMHO, it makes sense to remove the files from there, and add a pointer there (README?) to the new tree.
I will remove the scanfiles from there, add/edit the readme that the tree is a dependancy?
Quoted 4 lines
Regards,
Mauro.
Oliver
Em Wed, 09 Jan 2013 15:44:30 +0100
Oliver Schinagl <[email protected]> escreveu:
Quoted 13 lines
Mauro,
Quoted 9 lines · Mauro Carvalho Chehab
Hi Oliver,
Em Wed, 09 Jan 2013 13:24:13 +0100
Oliver Schinagl <[email protected]> escreveu:Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
If I understood it right, you want to split the scan files into a separate git tree and maintain it, right?
I'm ok with that.
<snip>
Quoted 8 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
I also migrated the dvb-apps changesets with the tables to:
http://git.linuxtv.org/dtv-scan-tables.git Feel free to maintain it.Thank you, this will be the new name for it (I will locally rename it) and try my bestest to maintain it :)
I will put a mention on the wiki 'how to submit scanfiles' (via the ML with tags in subject/pull requests) so people have a clear way how to submit them and I have a clear way to find them.
Great!
Quoted 6 lines
Quoted 4 lines
You should also have access to the dvb-apps hg tree. IMHO, it makes sense to remove the files from there, and add a pointer there (README?) to the new tree.
I will remove the scanfiles from there, add/edit the readme that the tree is a dependancy?
Please do it. You'll likely need to also add there at the tree a Makefile with an install target, in order to help distros to package it, and remove the corresponding scan files install Makefile targets at dvb-apps.
Signature · 2 lines
Cheers, Mauro
Quoted 26 lines · Mauro Carvalho Chehab
Em Wed, 09 Jan 2013 15:44:30 +0100
Oliver Schinagl <[email protected]> escreveu:Quoted 13 lines
Mauro,
Quoted 9 lines · Mauro Carvalho Chehab
Hi Oliver,
Em Wed, 09 Jan 2013 13:24:13 +0100
Oliver Schinagl <[email protected]> escreveu:Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
If I understood it right, you want to split the scan files into a separate git tree and maintain it, right?
I'm ok with that.
<snip>
Quoted 8 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
I also migrated the dvb-apps changesets with the tables to:
http://git.linuxtv.org/dtv-scan-tables.git Feel free to maintain it.Thank you, this will be the new name for it (I will locally rename it) and try my bestest to maintain it :)
I will put a mention on the wiki 'how to submit scanfiles' (via the ML with tags in subject/pull requests) so people have a clear way how to submit them and I have a clear way to find them.
Great!
Quoted 9 lines
Quoted 5 lines
Quoted 3 lines
You should also have access to the dvb-apps hg tree. IMHO, it makes sense to remove the files from there, and add a pointer there (README?) to the new tree.
I will remove the scanfiles from there, add/edit the readme that the tree is a dependancy?
Please do it. You'll likely need to also add there at the tree a
Makefilewith an install target, in order to help distros to package it, and remove the corresponding scan files installMakefiletargets at dvb-apps.
Will do as soon as I figure out how to gain access and and configure my local git install. I'm quite new to this multiple private key stuff and can't get it to work for now (i'll look into that for now). I feel stupid enough for asking :p
I'll first add my local patches and then see how i can 'fix' dvb-apps to remove the old stuff.
Quoted 8 lines · Oliver Schinagl
Quoted 7 lines · Johannes Stezenbach
Quoted 6 lines · Oliver Schinagl
Quoted 3 lines · Jiri Slaby
Quoted 1 line · Oliver Schinagl
Unfortunatly, I have had zero replies.
Hmm, it's sad there is a silence in this thread from linux-media guys :/.
In their defense, they are very very busy people ;) chatter on this thread does bring it up however.
Quoted 8 lines
Quoted 5 lines
This is such a nice thing to say :-)
But it might be that Mauro thinks the dvb-apps maintainer should respond, but apparently there is no dvb-apps maintainer... Maybe you should ask Mauro directly to create an account for you to implement what you proposed.Mauro is CC'ed and I'd ask of course for this (I kinda did) but who decides what I suggested is a good idea? I personally obviously think it is ;) and even more so if dvb-apps are unmaintained.
Well, if you become the dvb-apps maintainer, then _you_ decide if it's a good idea. That's part of the defintion of "maintainer" :-) It doesn't hurt to listen to users, but if no one comments you can do whatever you want with it.
But I'm only acting as kind of a webmaster, Mauro creates the accounts. So we have to wait for him to respond.
Quoted 3 lines
I guess the question now becomes 'who okay's this change? Who says 'okay, lets do it this way. Once that is answered we can go from there ;)
I guess you could ask the maintainer of the dvb-apps package of your favourite distribution for opinions, and also check which other packages depend on dvb-apps.
Johannes
Okay guys, I think this is a good time to discuss scan file maintenance [ should have taken care of it earlier, but well ...].
I've been updating the scan data for the past few years, but found barely no time in the last (many!) months. This won't change in future, so I've decided to step down from the task; may others do what is necessary ...
@Johannes: As I don't need the account anymore, please delete it.
Christoph
2013/1/7 Jiri Slaby <[email protected]>:
Quoted 46 lines · Oliver Schinagl
Quoted 1 line
Unfortunatly, I have had zero replies.
Hmm, it's sad there is a silence in this thread from linux-media guys :/.
Quoted 3 lines
So why bring it up again? On 2012/11/30 Jakub Kasprzycki provided us with updated polish DVB-T frequencies for his region. This has yet to be merged, almost 3 weeks later.
I sent a patch for cz data too:
https://patchwork.kernel.org/patch/1844201/Quoted 5 lines
I'll quickly repeat why I think this approach would be quite reasonable.
* dvb-apps binary changes don't result in unnecessary releases
* frequency updates don't result in unnecessary dvb-app releases
* Less strict requirements for commits (code reviews etc)Well the code should be reviewed still. See commit
a2e96055db297in your repo, it's bogus. The freq added is in kHz instead of MHz.Quoted 4 lines
* Possibly easier entry for new submitters
* much easier to package (tag it once per month if an update was)
* Separate maintainer possible
* just seems more logical to have it separated ;)The downside is you have to change the URL in kaffeine sources as kaffeine generates its scan file from that repo (on the server side and the client downloads then http://kaffeine.kde.org/scanfile.dvb.qz).
Quoted 1 line
This obviously should find a nice home on linuxtv where it belongs!
At best.
Quoted 5 lines
Here is my personal repository with the work I mentioned done.
git://git.schinagl.nl/dvb_frequency_scanfiles.gitIf an issue is that none of the original maintainers are not looking forward to do the job, I am willing to take maintenance on me for now.
Ping? Anybody? I would help with that too as I hate resending patches. But the first step I would do is a conversion to GIT. HG is demented to begin with.
--
js
Quoted 7 lines · Christoph Pfister
Okay guys, I think this is a good time to discuss scan file maintenance [ should have taken care of it earlier, but well ...].
I've been updating the scan data for the past few years, but found barely no time in the last (many!) months. This won't change in future, so I've decided to step down from the task; may others do what is necessary ...
Christoph, It's unfortunate that you decided to drop the ball. I will try to take care of it in the meanwhile..
Regards,
Manu
Hi Christoph,
Quoted 4 lines · Christoph Pfister
I've been updating the scan data for the past few years, but found barely no time in the last (many!) months. This won't change in future, so I've decided to step down from the task; may others do what is necessary ...
Thanks for your work over the past few years. If nobody else is willing, I'd be happy to take over this role, and if Oliver's offer still stands, I'd be happy to share DVB scanfile maintenance with him.
Jon
Quoted 10 lines · Jonathan McCrohan
Hi Christoph,
Quoted 4 lines · Christoph Pfister
I've been updating the scan data for the past few years, but found barely no time in the last (many!) months. This won't change in future, so I've decided to step down from the task; may others do what is necessary ...
Thanks for your work over the past few years. If nobody else is willing, I'd be happy to take over this role, and if Oliver's offer still stands, I'd be happy to share DVB scanfile maintenance with him.
Slightly depends on where this goes. If there is a seperated dvb-scanfile tree (or whatever incarnation can be thought of) I'd be happy to help out where I can.
The repository is 'done' imo. History is preserved and seperated out. Would just need some word from the powers that be. :)
Quoted 1 line
Jon
Quoted 2 lines · Christoph Pfister
@Johannes: As I don't need the account anymore, please delete it.
Done.
Thanks for the work you put into it!
Johannes