On 07/06/11 14:16, Vincent Danjean wrote:
> On 07/06/2011 14:36, Osamu Aoki wrote:
>> On Tue, Jun 07, 2011 at 12:54:23PM +0200, Vincent Danjean wrote:
>>> On 05/06/2011 07:39, Vincent Bernat wrote:
On Sat, 4 Jun 2011 21:54:11 +0200, Jonas Smedegaard wrote:
> What I do is use upstream
On 19/08/10 07:02, Goswin von Brederlow wrote:
> David Claughton writes:
>>> Legally that should be the same. And practically you would have the
>>> useless files on the initial source unpack but they would be gone when
>>> debian/rules is invoked the first time
On 18/08/10 09:29, Goswin von Brederlow wrote:
> David Claughton writes:
>
>> On 13/08/10 17:58, Russ Allbery wrote:
>>> Raphael Hertzog writes:
>>>
>>>> As suggested by Ian on -devel (see attachment), it would be nice to have
>>>> a wa
On 13/08/10 17:58, Russ Allbery wrote:
> Raphael Hertzog writes:
>
>> As suggested by Ian on -devel (see attachment), it would be nice to have
>> a way to remove files during unpack of a source package to hide non-free
>> files from our users without stripping them from the original tarball.
>
>
On 22/07/10 09:44, Jesús M. Navarro wrote:
> Hi, Manoj:
>
> On Thursday 22 July 2010 07:17:15 Manoj Srivastava wrote:
>> On Wed, Jul 21 2010, Will wrote:
>> > Also I imagine that it helps that they have some kind of commercial
>> > support behind their projects, whereas Debian has little/none of t
Hi Vincent,
Vincent Bernat wrote:
> Now, if upstream want to get patch Z, he can :
> - get patch Z for version X.Y
> - get patch between upstream (X+1).0 and master (X+1).0 containing
>patch Z and other stuff
>
Well, in this example there wouldn't be any "other stuff" - you would do
t
Hi,
Version 2.26.3 of Graphviz has been uploaded to experimental. This new
version is a significant jump from the existing 2.20 versions in stable
and testing.
The main differences are :
1. libagraph is no longer available - all packages now need to use
libcgraph instead. This should already
Charles Plessy wrote:
> [If I remember correctly, the question below is whether the law in the U.S.A.
> requires us to reproduce all copyright statements from the source files when
> we
> redistribute binary programs, or if this is only needed when the license
> expliciterly asks so.]
>
I believ
Bernhard R. Link wrote:
> As I said: I do not see a difference between a license that does not
> give me some right (or even tries to take away some rights copyright law
> does not take away) and a license which theoretically grant it but puts
> so many restrictions in it that one practically does
Bernhard R. Link wrote:
> * David Claughton [091114 12:43]:
>> I agree this makes the license problematic and might make developers
>> choose to avoid working on AGPL code - however as I said above, all
>> licenses put some limits on what you can modify, some more than other
Bernhard R. Link wrote:
> * David Claughton [091113 21:42]:
>> Now this could certainly involve more extensive modifications than you
>> might otherwise want to do, and you might well decide it's not worth the
>> effort. However I'm still not entirely convinced i
David Claughton wrote:
> The Fungi wrote:
>> goes a great deal further than this, by *requiring* you to become a
>> distributor of software you use, even if you only do something so
>> simple as make a minor modification to an AGPL-covered work
>> providing a network
The Fungi wrote:
> On Thu, Nov 12, 2009 at 11:07:12PM +0000, David Claughton wrote:
> [...]
>> It is always possible to modify free software in ways that effectively
>> make it non-free - for example if you remove all the copyright
>> statements from a BSD covered progr
The Fungi wrote:
> On Thu, Nov 12, 2009 at 09:28:59PM +0000, David Claughton wrote:
> [...]
>> You might want to, but AFAICT you would not be able to distribute
>> the result if the user cannot be told how to get the source to the
>> AGPL parts you included. That doesn'
Martin Langhoff wrote:
> On Thu, Nov 12, 2009 at 8:40 AM, Mike Hommey wrote:
>> Stupid question: with this wording of the AGPL, who, in his right mind,
>> will be licensing a DNS or POP server under this license ? (Except maybe
>> someone who didn't read it)
>
> There are lots of people who pick
Daniel Moerner wrote:
> On 08/12/2009 03:01 PM, David Claughton wrote:
>> Manoj Srivastava wrote:
>>> On Wed, Aug 12 2009, Neil Williams wrote:
>>>
>>>> On Wed, 12 Aug 2009 08:16:14 -0500
>>>> Manoj Srivastava wrote:
>>>> * updated
Manoj Srivastava wrote:
> On Wed, Aug 12 2009, Neil Williams wrote:
>
>> On Wed, 12 Aug 2009 08:16:14 -0500
>> Manoj Srivastava wrote:
>> * updated Standards-Version (no changes needed)
>
> Firstly, you do not ahve to put that into the changelog, and,
> secondly, one should not have t
Michael Shuler wrote:
> You're right. Ben pointed to the xen patch directory in the linux-2.6
> source package in his reply - the package build should not fetch the
> repo. I just spoke up (probably incorrectly, without asking for more
> info) to help with what I thought he was seeing.
>
OK, fa
Michael Shuler wrote:
> On 06/09/2009 11:49 AM, Andreas wrote:
>> Installing it (make), it downloads the binary of the hypervisor!
>> "Cloning http://xenbits.xensource.com/linux-2.6.18-xen.hg " #
>> (downloading)
>
> This is an incorrect understanding of that download step - it is a
> *source
Felipe Sateler wrote:
Juan Céspedes wrote:
invoke-rc.d is present since version 2.80-1 of sysvinit; maybe someone
could have a modern package with a very old sysvinit, and thus without
invoke-rc.d
But oldstable has 2.86.ds1-1. I thought that only direct upgrades were
supported. I guess the co
Amaya wrote:
In most cases the fix should be simple, replace this:
/etc/init.d/package
with this:
if which invoke-rc.d >/dev/null 2>&1; then
invoke-rc.d package
else
/etc/init.d/package
fi
Hi,
I don't want to be a pest (given I'm not
François Févotte wrote:
I'm not an expert at all, so I might be wrong. I guess this would be
the case if your source package compiled a statically linked binary
against a library belonging to another source package. The licence of
the binary package would then be a combination of the licences of
Sam Hocevar wrote:
That's right, we don't know the licensing terms of binary files.
But if we stop at the "it's not sufficient" argument, we'll never get
anywhere, because it is impossible for a source package to determine the
exact licensing terms of its binary packages. I'll leave that to a
Luk Claes wrote:
David Claughton wrote:
Is it useful to have bugs already fixed in sid included in the list for
BSP purposes? I would have thought "bydist=both" would be more
appropriate.
You might want to read the section Testing-only bugs at [0] on why lenny-only
bugs mig
Martin Zobel-Helas wrote:
where to find available RC bugs:
http://bts.turmzimmer.net/details.php?ignore=sid&ignnew=on&new=5
I'm just curious - the "ignore=sid" part means exclude bugs that only
affect sid, correct? Which means bugs which affect lenny but are
already fixed in sid are still
25 matches
Mail list logo
