libxdot4 libgraphviz-dev graphviz-doc graphviz-dev
Architecture: source all kfreebsd-amd64
Version: 2.26.3-16
Distribution: unstable
Urgency: medium
Maintainer: David Claughton d...@eclecticdave.com
Changed-By: David Claughton d...@eclecticdave.com
Description:
graphviz - rich set of graph drawing
libxdot4 libgraphviz-dev graphviz-doc graphviz-dev
Architecture: source all kfreebsd-amd64
Version: 2.26.3-14
Distribution: unstable
Urgency: low
Maintainer: David Claughton d...@eclecticdave.com
Changed-By: David Claughton d...@eclecticdave.com
Description:
graphviz - rich set of graph drawing tools
libxdot4 libgraphviz-dev graphviz-doc graphviz-dev
Architecture: source all kfreebsd-amd64
Version: 2.26.3-13
Distribution: unstable
Urgency: low
Maintainer: David Claughton d...@eclecticdave.com
Changed-By: David Claughton d...@eclecticdave.com
Description:
graphviz - rich set of graph drawing tools
libxdot4 libgraphviz-dev graphviz-doc graphviz-dev
Architecture: source all amd64
Version: 2.26.3-12
Distribution: unstable
Urgency: low
Maintainer: David Claughton d...@eclecticdave.com
Changed-By: David Claughton d...@eclecticdave.com
Description:
graphviz - rich set of graph drawing tools
graphviz
libxdot4 libgraphviz-dev graphviz-doc graphviz-dev
Architecture: source all amd64
Version: 2.26.3-11
Distribution: unstable
Urgency: low
Maintainer: David Claughton d...@eclecticdave.com
Changed-By: David Claughton d...@eclecticdave.com
Description:
graphviz - rich set of graph drawing tools
graphviz
libxdot4 libgraphviz-dev graphviz-doc graphviz-dev
Architecture: source all amd64
Version: 2.26.3-10
Distribution: unstable
Urgency: low
Maintainer: David Claughton d...@eclecticdave.com
Changed-By: David Claughton d...@eclecticdave.com
Description:
graphviz - rich set of graph drawing tools
graphviz
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 provided tarballs,
libgvpr1 libxdot4 libgraphviz-dev graphviz-doc
graphviz-dev
Architecture: source all amd64
Version: 2.26.3-6
Distribution: unstable
Urgency: low
Maintainer: David Claughton d...@eclecticdave.com
Changed-By: David Claughton d...@eclecticdave.com
Description:
graphviz - rich set of graph drawing tools
On 19/08/10 07:02, Goswin von Brederlow wrote:
David Claughton d...@eclecticdave.com 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. dpkg-source -x could
On 18/08/10 09:29, Goswin von Brederlow wrote:
David Claughton d...@eclecticdave.com writes:
On 13/08/10 17:58, Russ Allbery wrote:
Raphael Hertzog hert...@debian.org writes:
As suggested by Ian on -devel (see attachment), it would be nice to have
a way to remove files during unpack
On 13/08/10 17:58, Russ Allbery wrote:
Raphael Hertzog hert...@debian.org 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
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 that.
libgvpr1 libxdot4 libgraphviz-dev graphviz-doc
graphviz-dev
Architecture: source all i386
Version: 2.26.3-5
Distribution: unstable
Urgency: low
Maintainer: David Claughton d...@eclecticdave.com
Changed-By: David Claughton d...@eclecticdave.com
Description:
graphviz - rich set of graph drawing
libgraphviz-dev graphviz-doc graphviz-dev
Architecture: source all i386
Version: 2.26.3-4
Distribution: unstable
Urgency: low
Maintainer: David Claughton d...@eclecticdave.com
Changed-By: David Claughton d...@eclecticdave.com
Description:
graphviz - rich set of graph drawing tools
graphviz-dev
libgraphviz-dev graphviz-doc graphviz-dev
Architecture: source all i386
Version: 2.26.3-3
Distribution: unstable
Urgency: low
Maintainer: David Claughton d...@eclecticdave.com
Changed-By: David Claughton d...@eclecticdave.com
Description:
graphviz - rich set of graph drawing tools
graphviz-dev
libgraphviz-dev graphviz-doc graphviz-dev
Architecture: source all i386
Version: 2.26.3-2
Distribution: unstable
Urgency: low
Maintainer: David Claughton d...@eclecticdave.com
Changed-By: David Claughton d...@eclecticdave.com
Description:
graphviz - rich set of graph drawing tools
graphviz-dev
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
the
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
kfreebsd-i386 source
Version: 2.20.2-8
Distribution: unstable
Urgency: low
Maintainer: David Claughton d...@eclecticdave.com
Changed-By: David Claughton d...@eclecticdave.com
Closes: 566287
Description:
graphviz-dev - transitional package for graphviz-dev rename
graphviz-doc - additional
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 believe
Bernhard R. Link wrote:
* David Claughton d...@eclecticdave.com [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 it makes the license
Bernhard R. Link wrote:
* David Claughton d...@eclecticdave.com [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 others
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 not
The Fungi wrote:
On Thu, Nov 12, 2009 at 11:07:12PM +, 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 program.
[...]
This is untrue
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 service.
You are only required
Martin Langhoff wrote:
On Thu, Nov 12, 2009 at 8:40 AM, Mike Hommey m...@glandium.org 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
The Fungi wrote:
On Thu, Nov 12, 2009 at 09:28:59PM +, 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't mean the original software
isn't
Manoj Srivastava wrote:
On Wed, Aug 12 2009, Neil Williams wrote:
On Wed, 12 Aug 2009 08:16:14 -0500
Manoj Srivastava sriva...@debian.org wrote:
* updated Standards-Version (no changes needed)
Firstly, you do not ahve to put that into the changelog, and,
secondly, one should
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 sriva...@debian.org wrote:
* updated Standards-Version (no changes needed)
Firstly, you do
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* download
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, fair
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
Amaya wrote:
In most cases the fix should be simple, replace this:
/etc/init.d/package action
with this:
if which invoke-rc.d /dev/null 21; then
invoke-rc.d package action
else
/etc/init.d/package action
fi
Hi,
I don't want to be a pest
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
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
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 might also
Martin Zobel-Helas wrote:
where to find available RC bugs:
http://bts.turmzimmer.net/details.php?ignore=sidignnew=onnew=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
37 matches
Mail list logo
