Quoting Andreas Cadhalpun (2014-11-27 00:35:14)
> On 26.11.2014 23:48, Jonas Smedegaard wrote:
>> Quoting Andreas Cadhalpun (2014-11-26 22:53:57)
>>> Therefore I don't consider this problem currently as
>>> release-critical. That would be different, if libavcodec-extra was
>>> the default.
>>
>>
Hi,
On 26.11.2014 23:48, Jonas Smedegaard wrote:
Quoting Andreas Cadhalpun (2014-11-26 22:53:57)
On 23.11.2014 20:03, Jonas Smedegaard wrote:
As I understand this particular case, Debian doesn't violate the
license direc. It would only be violated if a Debian user distributed
one of the GPL v2
Quoting Andreas Cadhalpun (2014-11-26 22:53:57)
> On 23.11.2014 20:03, Jonas Smedegaard wrote:
>> If you stumble across a license violation in Debian - be it in
>> experimental, backports, freeze or oldstable - file a very severe
>> bugreport about it. Yes, so severe that the issue *must* be dea
Hi Jonas,
On 23.11.2014 20:03, Jonas Smedegaard wrote:
If you stumble across a license violation in Debian - be it in
experimental, backports, freeze or oldstable - file a very severe
bugreport about it. Yes, so severe that the issue *must* be dealt with,
and if by no othere means then by remov
Quoting Andreas Cadhalpun (2014-11-23 19:42:23)
> On 23.11.2014 03:09, Reinhard Tartler wrote:
>> On Sat, Nov 22, 2014 at 6:51 AM, Andreas Cadhalpun
>>> The problem here is that it might seem to affect only few packages,
>>> but nobody has really looked, so we can't know. In particular, it's
>>>
Hi,
On 23.11.2014 03:09, Reinhard Tartler wrote:
On Sat, Nov 22, 2014 at 6:51 AM, Andreas Cadhalpun
wrote:
That's a nice idea, but just as the shlibs.local method, it doesn't work in
all cases. See my previous example of libkfilemetadata4, which would still
have the problem, because it only in
On Nov 23, 2014 6:14 AM, "Jonas Smedegaard" wrote:
>
> Quoting Reinhard Tartler (2014-11-23 02:57:33)
> > On Thu, Nov 20, 2014 at 9:02 PM, Jonas Smedegaard wrote:
> >> Quoting Reinhard Tartler (2014-11-20 21:45:56)
> >>> On Nov 20, 2014 3:01 PM, "Jonas Smedegaard" <[1]d...@jones.dk> wrote:
>
Quoting Reinhard Tartler (2014-11-23 02:57:33)
> On Thu, Nov 20, 2014 at 9:02 PM, Jonas Smedegaard wrote:
>> Quoting Reinhard Tartler (2014-11-20 21:45:56)
>>> On Nov 20, 2014 3:01 PM, "Jonas Smedegaard" <[1]d...@jones.dk> wrote:
Quoting Andreas Cadhalpun (2014-11-20 17:09:49)
> On 19.11.
On Sat, Nov 22, 2014 at 6:51 AM, Andreas Cadhalpun
wrote:
> Hi,
>
> On 22.11.2014 10:11, Fabian Greffrath wrote:
>>
>> I have two more ideas regarding this issue:
>>
>> 1) We have two library packages that conflict with each other. Why don't
>> we have two -dev packages that conflict with each oth
On Sat, Nov 22, 2014 at 4:11 AM, Fabian Greffrath wrote:
> I have two more ideas regarding this issue:
>
> 1) We have two library packages that conflict with each other. Why don't
> we have two -dev packages that conflict with each other, then?
>
> I suggest to introduce a new libavcodec-extra-dev
On Thu, Nov 20, 2014 at 9:02 PM, Jonas Smedegaard wrote:
> Hi Reinhard,
>
> Quoting Reinhard Tartler (2014-11-20 21:45:56)
>> On Nov 20, 2014 3:01 PM, "Jonas Smedegaard" <[1]d...@jones.dk> wrote:
>>> Quoting Andreas Cadhalpun (2014-11-20 17:09:49)
On 19.11.2014 13:09, Jonas Smedegaard wrote:
Hi,
On 22.11.2014 13:48, Felipe Sateler wrote:
On Sat, Nov 22, 2014 at 8:51 AM, Andreas Cadhalpun
wrote:
That's a nice idea, but just as the shlibs.local method, it doesn't work in
all cases. See my previous example of libkfilemetadata4, which would still
have the problem, because it only indi
On Sat, Nov 22, 2014 at 8:51 AM, Andreas Cadhalpun
wrote:
> Hi,
>
> On 22.11.2014 10:11, Fabian Greffrath wrote:
>>
>> I have two more ideas regarding this issue:
>>
>> 1) We have two library packages that conflict with each other. Why don't
>> we have two -dev packages that conflict with each oth
Hi,
On 22.11.2014 10:11, Fabian Greffrath wrote:
I have two more ideas regarding this issue:
1) We have two library packages that conflict with each other. Why don't
we have two -dev packages that conflict with each other, then?
I suggest to introduce a new libavcodec-extra-dev package that de
Quoting Fabian Greffrath (2014-11-22 10:11:43)
> I have two more ideas regarding this issue:
>
> 1) We have two library packages that conflict with each other. Why don't
> we have two -dev packages that conflict with each other, then?
>
> I suggest to introduce a new libavcodec-extra-dev package
I have two more ideas regarding this issue:
1) We have two library packages that conflict with each other. Why don't
we have two -dev packages that conflict with each other, then?
I suggest to introduce a new libavcodec-extra-dev package that depends
on "libavcodec | libavcodec-extra" and change
Hi Reinhard,
Quoting Reinhard Tartler (2014-11-20 21:45:56)
> On Nov 20, 2014 3:01 PM, "Jonas Smedegaard" <[1]d...@jones.dk> wrote:
>> Quoting Andreas Cadhalpun (2014-11-20 17:09:49)
>>> On 19.11.2014 13:09, Jonas Smedegaard wrote:
Possibly we can simplify even further:
* Have pack
On Nov 20, 2014 3:01 PM, "Jonas Smedegaard" wrote:
>
> Quoting Andreas Cadhalpun (2014-11-20 17:09:49)
> > On 19.11.2014 13:09, Jonas Smedegaard wrote:
> >> Possibly we can simplify even further:
> >>
> >>* Have package libavcodec-extra-NN provide virtual libavcodec-extra
> >> (i.e. non-v
Hi,
On 20.11.2014 21:00, Jonas Smedegaard wrote:
Quoting Andreas Cadhalpun (2014-11-20 17:09:49)
On 19.11.2014 13:09, Jonas Smedegaard wrote:
Possibly we can simplify even further:
* Have package libavcodec-extra-NN provide virtual libavcodec-extra
(i.e. non-versioned name of itself
Quoting Andreas Cadhalpun (2014-11-20 17:09:49)
> On 19.11.2014 13:09, Jonas Smedegaard wrote:
>> Possibly we can simplify even further:
>>
>>* Have package libavcodec-extra-NN provide virtual libavcodec-extra
>> (i.e. non-versioned name of itself)
>>* Let GPLv2 packages conflict again
Hi,
On 19.11.2014 13:09, Jonas Smedegaard wrote:
Possibly we can simplify even further:
* Have package libavcodec-extra-NN provide virtual libavcodec-extra
(i.e. non-versioned name of itself)
* Let GPLv2 packages conflict against libavcodec-extra (i.e. not
replace but complement
Hi,
On 19.11.2014 15:25, Reinhard Tartler wrote:
On Nov 19, 2014 8:24 AM, "Nicolas George" mailto:geo...@nsup.org>> wrote:
> It is perfectly legal and compatible with the license to USE a GPLv2
> program with a GPLv3 shared library or the other way around. Licenses can
> only control distribu
Hi,
On 19.11.2014 04:02, Reinhard Tartler wrote:
On Tue, Nov 18, 2014 at 5:55 PM, Andreas Cadhalpun
wrote:
Furthermore I don't think it can always work.
For example look at the dependencies of libkfilemetadata4:
* libavformat56, which depends on libavcodec56 | libavcodec-extra-56
* libpopp
Am Mittwoch, den 19.11.2014, 20:09 +0100 schrieb Nicolas George:
> And as a consequence, people who develop new multimedia software can not
> have the extra codecs, and people who need the extra codecs are not allowed
> to develop or build software. I do not think this is a very good idea.
Phew,
Le nonidi 29 brumaire, an CCXXIII, Fabian Greffrath a écrit :
> All we need to do is drop the alternative dependency of libavcodec-dev
> on libavcodec-extra. The regular library package that libavcodec-dev
> then solely depends on will conflict the -extra package out of the way
> if this was instal
Am Mittwoch, den 19.11.2014, 15:10 +0100 schrieb Jonas Smedegaard:
> Good point.
Valid point, indeed!
> How do you then find my above post, replacing "conflict" with
> "build-conflict"?
All we need to do is drop the alternative dependency of libavcodec-dev
on libavcodec-extra. The regular libr
On Nov 19, 2014 8:24 AM, "Nicolas George" wrote:
>
> Le nonidi 29 brumaire, an CCXXIII, Jonas Smedegaard a écrit :
> > Possibly we can simplify even further:
> >
> > * Have package libavcodec-extra-NN provide virtual libavcodec-extra
> > (i.e. non-versioned name of itself)
> > * Let GPLv2
Quoting Nicolas George (2014-11-19 13:48:14)
> Le nonidi 29 brumaire, an CCXXIII, Jonas Smedegaard a écrit :
>> Possibly we can simplify even further:
>>
>> * Have package libavcodec-extra-NN provide virtual libavcodec-extra
>> (i.e. non-versioned name of itself)
>> * Let GPLv2 packages co
Le nonidi 29 brumaire, an CCXXIII, Jonas Smedegaard a écrit :
> Possibly we can simplify even further:
>
> * Have package libavcodec-extra-NN provide virtual libavcodec-extra
> (i.e. non-versioned name of itself)
> * Let GPLv2 packages conflict against libavcodec-extra (i.e. not
> rep
Quoting Reinhard Tartler (2014-11-19 04:02:42)
>>> What could be considered problematic is that users technically do a
>>> license violation by installing libavcodec-extra-NN together with
>>> GPLv2 only packages. On might construct a situation where some
>>> Debian user creates an appliance tha
On Tue, Nov 18, 2014 at 5:55 PM, Andreas Cadhalpun
wrote:
>> What could be considered problematic is that users technically do a
>> license violation by installing libavcodec-extra-NN together with
>> GPLv2 only packages. On might construct a situation where some Debian
>> user creates an applian
Hi,
On 18.11.2014 01:25, Reinhard Tartler wrote:
On Mon, Nov 17, 2014 at 5:53 PM, Andreas Cadhalpun
wrote:
All of them have an alternative dependency on libavcodec-extra-56, which is
strictly speaking a license violation.
Probably appropriate Conflicts relationships between them and
libavcodec
Quoting Reinhard Tartler (2014-11-18 01:25:18)
> On Mon, Nov 17, 2014 at 5:53 PM, Andreas Cadhalpun
>> However, I wonder if the few additional codecs in the extra package
>> are worth all the additional complexity. How many actually use these
>> codecs?
>
> We used to ship x264 in the -extra- pac
On Mon, Nov 17, 2014 at 5:53 PM, Andreas Cadhalpun
wrote:
> Hi,
>
> On 13.11.2014 15:12, Fabian Greffrath wrote:
>>
>> Right, I believe there are many libavcodec-using packages out there that
>> are licensed under GPLv3 or similar licenses, whereas we forcefully keep
>> the default library package
On Thu, Nov 13, 2014 at 9:12 AM, Fabian Greffrath wrote:
> Am Donnerstag, den 13.11.2014, 08:34 -0500 schrieb Reinhard Tartler:
>> >From vlc's debian/changelog:
>> [...]
>> However, this package is linked to LGPL v3 libraries. So while the source is
>> GPL v2 or later, this package is GPL v3
>> [.
Hi,
On 13.11.2014 15:12, Fabian Greffrath wrote:
Right, I believe there are many libavcodec-using packages out there that
are licensed under GPLv3 or similar licenses, whereas we forcefully keep
the default library package at GPLv2. Are there any counter-examples?
Several packages using libavc
Am Donnerstag, den 13.11.2014, 15:12 +0100 schrieb Fabian Greffrath:
> The question is, how so we do this in the most clean way? Three
> alternatives come to mind:
> 1) shlibs.local file
> 2) modified dh_makeshlibs, dh_shlibdeps, dh_makeshlibs sequence
> 3) manual dependencies like the -dev packag
Am Donnerstag, den 13.11.2014, 08:34 -0500 schrieb Reinhard Tartler:
> >From vlc's debian/changelog:
> [...]
> However, this package is linked to LGPL v3 libraries. So while the source is
> GPL v2 or later, this package is GPL v3
> [...]
But this speaks against the split.
> I'm wouldn't be surpr
On Tue, Nov 11, 2014 at 6:41 AM, Fabian Greffrath wrote:
> Am Freitag, den 21.02.2014, 08:45 +0530 schrieb shirish शिरीष:
>> Can somebody state for the reasons of a split of libavcodec54 and
>> libavcodec-extra-54 ? The only diff. I could see between both of them
>> are/were the three decoders whi
Am Freitag, den 21.02.2014, 08:45 +0530 schrieb shirish शिरीष:
> Can somebody state for the reasons of a split of libavcodec54 and
> libavcodec-extra-54 ? The only diff. I could see between both of them
> are/were the three decoders which are in the extra-54 which are not in
> libavcodec54.
Could
Quoting Nicolas George (2014-02-22 15:02:37)
> Le quartidi 4 ventôse, an CCXXII, shirish शिरीष a écrit :
>> On the ffmpeg side there seems to be some movement happening.
>>
>> http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2014-February/154080.html
>>
>> If memory serves right, whatever happens in
Le quartidi 4 ventôse, an CCXXII, shirish शिरीष a écrit :
> On the ffmpeg side there seems to be some movement happening.
>
> http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2014-February/154080.html
>
> If memory serves right, whatever happens in ffmpeg does get mirrored
> by people who are worki
in-line :-
On 2/21/14, Fabian Greffrath wrote:
> Hi shirish,
>
> Am Freitag, den 21.02.2014, 08:45 +0530 schrieb shirish शिरीष:
>> I have tripped on it whenever I'm installing the package on some
>> friend's, acquaintance's system. Can anybody clarify ? I would love to
>> add the reasoning to the
On Fri, Feb 21, 2014 at 12:15 AM, shirish शिरीष wrote:
> Lastly, is there a possibility of having a metapackage so people could
> have all of it in one go ? Codecs, video player, the works.
>
> something like :-
>
> $ apt-get install debian-multimedia
If you do find some packages that improve dec
Hi shirish,
Am Freitag, den 21.02.2014, 08:45 +0530 schrieb shirish शिरीष:
> I have tripped on it whenever I'm installing the package on some
> friend's, acquaintance's system. Can anybody clarify ? I would love to
> add the reasoning to the wiki page
> https://wiki.debian.org/MultimediaCodecs .
Hi all,
Can somebody state for the reasons of a split of libavcodec54 and
libavcodec-extra-54 ? The only diff. I could see between both of them
are/were the three decoders which are in the extra-54 which are not in
libavcodec54.
I searched the archives over a year and a little above but didn't see
46 matches
Mail list logo
