Re: on bootstrapping ports (was: Re: Bits from the Release Team (Jessie freeze info))
On Monday, October 28, 2013 12:15:09 PM Emmanuel Bourg wrote: Le 27/10/2013 16:30, Daniel Schepler a écrit : (To be honest, the Java packages are such a tangled mess that I've given up on trying to bootstrap that part of the archive for now -- and many of those do get pulled into the minimal set of ca. 1473 source packages I get with my criteria.) Hi Daniel, could you elaborate on the tangled mess of the Java packages? As someone who cares about the Java packages in general I'd be interested in hearing what could be improved. (Let's take any more detailed discussions on this off debian-devel and leave it just on debian-java.) The first task would be to bootstrap gcj and then openjdk (and the latter's binary dependencies on libatk-wrapper-java-jni, ca-certificates-java, tzdata- java). Then I have to bootstrap ant, which is made difficult by the fact that there are so many Build-Depends needed before it's possible to build a full version of ant-optional. In the past I've done that by first building just ant from that package, and then whenever one of the indirect Build-Depends of ant- optional has a Build-Depends on ant-optional itself, I build a throwaway version of ant-optional against whatever I have available at that point. But now, with libgnumail-java having a Build-Depends on bnd which Build-Depends on some packages from eclipse, I don't really have any idea how to handle that, other than to drop the call to bnd and cross my fingers hoping nothing needs whatever the bnd call adds to that package. Mixed in with that, I also have to bootstrap maven-repo-helper, and for a few packages that I need before I'm able to do that, I do the ugly thing of just taking the metadata files from existing packages and installing them by hand into bootstrapped packages. Then, the next major hurdle is that many packages that are part of the Maven build system or its binary dependencies have Build- Depends on maven-debian-helper themselves. A while ago I figured out a way to bootstrap this using maven-ant-helper, but that's a long drawn-out process involving probably hundreds of packages. And I'm not sure that my process will still work, as there are even more packages that have switched to using maven-debian-helper to build in the meantime, including libjaxen-java which has always been a headache because of its circular Build-Depends with dom4j, libjdom1-java, xom. (Also, maven-ant-helper itself isn't necessarily that easy to bootstrap, as it Build-Depends on ant-contrib, which Build-Depends on ivy, which Build-Depends on libcommons-vfs-java, which needs maven-debian- helper.) And yes, maven-debian-helper is part of that set of ca. 1473 source packages, for example via the chain x11proto-core - fop - xmlgraphics- commons - mockito - objenesis - maven-debian-helper. Anyway, that's just an overview of the main issues I face with a bootstrap of the Java packages. If you want, I could restart my bootstrap process and let you know in more detail what Build-Depends cycles I run into (and solutions where I've been able to find them in past iterations). Obviously, though, very little of this will be relevant for the case of bootstrapping a new port, using the existing Architecture: all packages. -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2411641.bXzH0chkUq@frobozz
Re: on bootstrapping ports (was: Re: Bits from the Release Team (Jessie freeze info))
Le 27/10/2013 16:30, Daniel Schepler a écrit : (To be honest, the Java packages are such a tangled mess that I've given up on trying to bootstrap that part of the archive for now -- and many of those do get pulled into the minimal set of ca. 1473 source packages I get with my criteria.) Hi Daniel, could you elaborate on the tangled mess of the Java packages? As someone who cares about the Java packages in general I'd be interested in hearing what could be improved. Emmanuel Bourg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/526e473d.7070...@apache.org
Re: on bootstrapping ports (was: Re: Bits from the Release Team (Jessie freeze info))
On Sun, Oct 27, 2013 at 4:33 PM, Johannes Schauer wrote: Surely every maintainer of source packages involved in a Type 1 Self-Cycle knows about this issue. Because Type 2 Self-Cycles are non-obvious we could in the future (once build profiles are available) embed this information in the pts for the relevant packages. On the other hand, there only exist a small number (26 for amd64) source packages involved in Type 2 Self-Cycles so it might be enough to just post priority wishlist bug reports for each of them. Please do file a bug on the PTS (qa.debian.org, usertag pts) about this when the appropriate machine-readable package list and human-readable explanations are available. But it does not allow continuous testing of bootstrappability of the whole archive. This might be interesting information to have on edos.debian.net or elsewhere on Debian QA infrastructure. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6edwqggqxw7ks2jwft83eo-ct0un6s2gyzuqcdpb-y...@mail.gmail.com
Re: on bootstrapping ports (was: Re: Bits from the Release Team (Jessie freeze info))
Johannes Schauer wrote:
Indeed, none of the Type 1 Self-Cycles are needed to bootstrap the core of
Debian. Unfortunately though, most of the Type 2 Self-Cycles are. You will
find
many surprising (at least to me) examples in the section of Type 2
Self-Cycles under the above link.
On the other hand, if you count Build-Depends-Indep and Architecture: all
packages as part of what you want to bootstrap, then gnat-4.6 does get pulled
in...
gzip Build-Depends-Indep: mingw-w64
mingw-w64 Build-Depends: gcc-mingw-w64-{i686,x86_64}
gcc-mingw-w64 Build-Depends: gnat-4.6
(And also, you have the issue that gcc-4.8 Build-Depends on libantlr-java and
libecj-java, whose builds require either gcj-4.8 from the same source package,
or openjdk-7-jdk which also Build-Depends on ecj.)
I realize that these sorts of issues aren't as important for the practical
problem of bootstrapping a new port; but ideally, from a philosophical point
of view we should be able to bootstrap all our packages. (To be honest, the
Java packages are such a tangled mess that I've given up on trying to
bootstrap that part of the archive for now -- and many of those do get pulled
into the minimal set of ca. 1473 source packages I get with my criteria.)
--
Daniel Schepler
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2085384.4n0ClPvkx6@frobozz
Re: on bootstrapping ports (was: Re: Bits from the Release Team (Jessie freeze info))
Hi Daniel,
Quoting Daniel Schepler (2013-10-27 16:06:43)
Johannes Schauer wrote:
Indeed, none of the Type 1 Self-Cycles are needed to bootstrap the core of
Debian. Unfortunately though, most of the Type 2 Self-Cycles are. You will
find
many surprising (at least to me) examples in the section of Type 2
Self-Cycles under the above link.
On the other hand, if you count Build-Depends-Indep and Architecture: all
packages as part of what you want to bootstrap, then gnat-4.6 does get pulled
in...
gzip Build-Depends-Indep: mingw-w64
mingw-w64 Build-Depends: gcc-mingw-w64-{i686,x86_64}
gcc-mingw-w64 Build-Depends: gnat-4.6
(And also, you have the issue that gcc-4.8 Build-Depends on libantlr-java and
libecj-java, whose builds require either gcj-4.8 from the same source
package,
or openjdk-7-jdk which also Build-Depends on ecj.)
I realize that these sorts of issues aren't as important for the practical
problem of bootstrapping a new port; but ideally, from a philosophical point
of view we should be able to bootstrap all our packages. (To be honest, the
Java packages are such a tangled mess that I've given up on trying to
bootstrap that part of the archive for now -- and many of those do get pulled
into the minimal set of ca. 1473 source packages I get with my criteria.)
you can easily use botch for an analysis of dependency cycles under your
conditions as well. Botch is a collection of tools doing some mangling with
sets of binary and source package metadata and creating and analyzing a graph
build from them. By calling the involved tools a bit differently than it is
done in the example shell script (which is to demonstrate the practical
bootstrap scenario and thus drops B-D-I and arch:all) you can also analyze the
situation you are talking about.
More specifically, you want to change how the create_graph binary is called.
The --available option expects a filename of a file containing the list of
packages which is expected to be available in the bootstrapping sense [1].
This file is currently compiled containing all arch:all and all cross compiled
binary packages. You are free to not add any arch:all packages or only some to
that list.
Secondly, per default B-D-I dependencies are ignored but you can pass the
--keep-indep argument to the create_graph binary to let them be considered
nevertheless.
cheers, josch
[1] https://gitorious.org/debian-bootstrap/pages/Terminology#Availability
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131027152758.16796.78747@hoothoot
Re: on bootstrapping ports (was: Re: Bits from the Release Team (Jessie freeze info))
Am 27.10.2013 16:06, schrieb Daniel Schepler:
Johannes Schauer wrote:
Indeed, none of the Type 1 Self-Cycles are needed to bootstrap the core of
Debian. Unfortunately though, most of the Type 2 Self-Cycles are. You will
find
many surprising (at least to me) examples in the section of Type 2
Self-Cycles under the above link.
On the other hand, if you count Build-Depends-Indep and Architecture: all
packages as part of what you want to bootstrap, then gnat-4.6 does get pulled
in...
gzip Build-Depends-Indep: mingw-w64
mingw-w64 Build-Depends: gcc-mingw-w64-{i686,x86_64}
gcc-mingw-w64 Build-Depends: gnat-4.6
(And also, you have the issue that gcc-4.8 Build-Depends on libantlr-java and
libecj-java, whose builds require either gcj-4.8 from the same source
package,
or openjdk-7-jdk which also Build-Depends on ecj.)
I realize that these sorts of issues aren't as important for the practical
problem of bootstrapping a new port; but ideally, from a philosophical point
of view we should be able to bootstrap all our packages. (To be honest, the
Java packages are such a tangled mess that I've given up on trying to
bootstrap that part of the archive for now -- and many of those do get pulled
into the minimal set of ca. 1473 source packages I get with my criteria.)
well, please can we concentrate on practical issues first, then come back to the
philosopicals again? With recent binary-indep packages you just cross-build
gcc-4.8 including java. Problem solved. I never did see a bug report about the
tangled mess in the java packages, so I'll just ignore that. gcj and openjdk
were one of the easier parts for the AArch64 bootstrap.
Matthias
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/526d497d@debian.org
