Hi,
Quoting Simon McVittie (2013-03-05 16:54:00)
On 05/03/13 11:22, Johannes Schauer wrote:
Since self-cycles in Debian are often unintuitive, maintainers might be
unaware
that the source packages they maintain are actually forming a self cycle.
This is useful information. Is there any
On 13141 March 1977, Johannes Schauer wrote:
The code generating that list is part of the debian bootstrap project [1]
and as such it would be a bug if architecture:all package were required to
be recompiled for the reason you mentioned.
In that case, rather than putting this up on a wiki
On 03/05/2013 10:46 AM, Johannes Schauer wrote:
Hi,
Quoting The Wanderer (2013-03-05 15:35:37)
You can build either one without a matching version of the other, but you
won't get full functionality. In order to get the full functionality of
both, from what I've been able to tell you need a
Hi,
Quoting The Wanderer (2013-03-06 14:46:49)
In that case, this (part of it) is a problem with my misunderstanding the
terminology being used.
The terminology is based upon the dependency representation in the dependency
graph. We have two different types of graph, the source graph which
Hi,
I wrote a shell script which outputs the following static html:
http://mister-muffin.de/bootstrap/selfcycles.html
If you guys find this useful, then I can see how to get this generated
periodically and published somewhere under the debian.org domain.
Quoting Joerg Jaspert (2013-03-06
Johannes Schauer, le Wed 06 Mar 2013 18:56:47 +0100, a écrit :
I wrote a shell script which outputs the following static html:
http://mister-muffin.de/bootstrap/selfcycles.html
If you guys find this useful, then I can see how to get this generated
periodically and published somewhere under
Hi,
[...]
CPU:
The whole script producing the output above took 7 hours to run on a 2.5GHz
Core i5 for all suites and all architectures (38 combinations). This is
because
generating strong strong dependencies for all packages in the archive takes
8-10 minutes with current archive sizes.
Hi,
Quoting Michael Tautschnig (2013-03-06 19:22:37)
What about parallelizing parts of the job?
Sure, the html page I linked to contains 38 different data points:
- 11 architectures from stable
- 13 architectures from testing
- 14 architectures from unstable
The most trivial way of
On 13142 March 1977, Johannes Schauer wrote:
That obviously depends a bit on what is actually needed to run (and then on
talking to DSA, but they don't bite so much :) ).
If it is found useful, then I have to figure out who to contact about
this.
For it to live on debian.org seperately ,
Hi,
Since self-cycles in Debian are often unintuitive, maintainers might be unaware
that the source packages they maintain are actually forming a self cycle. I
therefore created a wiki page with the list of the 81 self-cycles in Debian Sid
as of 2013-01-01:
Is there anything we can add to debcheck or the PTS to encourage
maintainers to help break these cycles by adding build profiles and or
cross-compilation info?
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of
Hello,
Johannes Schauer, le Tue 05 Mar 2013 12:22:46 +0100, a écrit :
as of 2013-01-01: http://wiki.debian.org/DebianBootstrap/SelfCycles
Maybe arch:all-only source packages should be shown in a different
color: AIUI these do not pose a problem for bootstrapping a new Debian
port, since one
Hi,
Quoting Samuel Thibault (2013-03-05 13:41:12)
Maybe arch:all-only source packages should be shown in a different color:
AIUI these do not pose a problem for bootstrapping a new Debian port, since
one does not need to build the source package, and just pick up the existing
_all.deb. They
On Tue, Mar 05, 2013 at 02:41:51PM +0100, Johannes Schauer wrote:
Hi,
Quoting Samuel Thibault (2013-03-05 13:41:12)
Maybe arch:all-only source packages should be shown in a different color:
AIUI these do not pose a problem for bootstrapping a new Debian port, since
one does not need to
Johannes Schauer, le Tue 05 Mar 2013 14:41:51 +0100, a écrit :
Quoting Samuel Thibault (2013-03-05 13:41:12)
Maybe arch:all-only source packages should be shown in a different color:
AIUI these do not pose a problem for bootstrapping a new Debian port, since
one does not need to build the
Hi,
Quoting Wouter Verhelst (2013-03-05 14:47:20)
On Tue, Mar 05, 2013 at 02:41:51PM +0100, Johannes Schauer wrote:
The code generating that list is part of the debian bootstrap project [1]
and as such it would be a bug if architecture:all package were required to
be recompiled for the
Hi,
Quoting Samuel Thibault (2013-03-05 14:57:04)
For instance commons-beanutils is only producing arch:all packages (I don't
understand why it has separate Build-Depends and Build-Depends-Indep BTW), so
AIUI, ports don't need to build it and thus do not have to care about the
dependency
At risk of making myself look like an idiot, I have a possibly contributory
question.
On 03/05/2013 06:22 AM, Johannes Schauer wrote:
Self-cycles can be divided into two classes:
1. a build dependency on a binary package the source package builds (the
simple case)
2. a build dependency
Hi,
Quoting The Wanderer (2013-03-05 15:35:37)
You can build either one without a matching version of the other, but you
won't get full functionality. In order to get the full functionality of both,
from what I've been able to tell you need a minimum of three builds on every
On 05/03/13 11:22, Johannes Schauer wrote:
Since self-cycles in Debian are often unintuitive, maintainers might be
unaware
that the source packages they maintain are actually forming a self cycle.
This is useful information. Is there any way in which the maintainers of
these packages can say
Hi,
Quoting Simon McVittie (2013-03-05 16:54:00)
This is useful information. Is there any way in which the maintainers of
these packages can say yes, we know, and here is where you break the cycle
without using unmerged dpkg features or breaking the freeze?
I'm afraid there is little one can
On Tue, Mar 05, 2013 at 08:28:15PM +0800, Paul Wise wrote:
Is there anything we can add to debcheck or the PTS to encourage
maintainers to help break these cycles by adding build profiles and or
cross-compilation info?
It seems to be premature to add build profiles to packages, as the
On Wed, Mar 6, 2013 at 6:20 AM, Steve Langasek wrote:
On Tue, Mar 05, 2013 at 08:28:15PM +0800, Paul Wise wrote:
Is there anything we can add to debcheck or the PTS to encourage
maintainers to help break these cycles by adding build profiles and or
cross-compilation info?
It seems to be
23 matches
Mail list logo