On Wed, 2013-01-30 at 17:27:13 +, Wookey wrote:
> +++ Ian Jackson [2013-01-16 13:50 +]:
>
> > * The concrete syntax in build-depends should not use < > but rather
> >reuse the architecture qualification syntax.
>
> I have just been told of a specific reason to avoid using '< >' :
> D
+++ Ian Jackson [2013-01-16 13:50 +]:
> * The concrete syntax in build-depends should not use < > but rather
>reuse the architecture qualification syntax.
I have just been told of a specific reason to avoid using '< >' :
DEP-11 proposes to use '< >' for Component metadata in binary packa
+++ Michael Biebl [2013-01-25 15:31 +0100]:
> Hi,
>
> looking over your proposal, I was missing a few things (sorry if this
> was mentioned in one of the replies, I've only skimmed over the thread).
>
> a/ It's good practice to explicitly enable/disable features via
> configure switches, to have
Hi,
looking over your proposal, I was missing a few things (sorry if this
was mentioned in one of the replies, I've only skimmed over the thread).
a/ It's good practice to explicitly enable/disable features via
configure switches, to have reliable build results in tainted build
environments. What
Hi,
On Fri, Jan 18, 2013 at 04:27:00PM -0800, Steve Langasek wrote:
> On Thu, Jan 17, 2013 at 08:33:57AM +0100, Wouter Verhelst wrote:
> > Now it might be that a package build-depends on our package foo
> > because it needs to translate documents in that XML format into
> > something else, With yo
Hi,
On Fri, 18 Jan 2013, Colin Watson wrote:
> Maybe this plan can be rescued, though. Provided that a version of the
> package is installed, the control field will be present in the status
> file; so, after you install the build-architecture version,
> dpkg-checkbuilddeps could look at that and
On Thu, Jan 17, 2013 at 08:33:57AM +0100, Wouter Verhelst wrote:
> However, to do that, there's one thing I'm missing in your mail: there
> will be cases where packages, when built in a particular profile do not
> support some functionality. That is, the package is available and does
> most of what
On Thu, Jan 17, 2013 at 09:51:32PM +0100, Wouter Verhelst wrote:
> On Thu, Jan 17, 2013 at 09:34:16AM +0100, Johannes Schauer wrote:
> > On Thu, Jan 17, 2013 at 08:33:57AM +0100, Wouter Verhelst wrote:
> > > If wanna-build is updated to support these two fields, then I imagine
> > > it can run the
On Fri, Jan 18, 2013 at 08:54:26AM +0100, Raphael Hertzog wrote:
> On Wed, 16 Jan 2013, Colin Watson wrote:
> > This is cleaner than any of the other options I've come up with: it
> > doesn't require hardcoding a list of "toolchain packages" that have
> > special cross versions; it would allow us t
Hi,
On Wed, 16 Jan 2013, Colin Watson wrote:
> This is cleaner than any of the other options I've come up with: it
> doesn't require hardcoding a list of "toolchain packages" that have
> special cross versions; it would allow us to stop having to shove
> pkg-config-HOST into cross-build chroots; a
On Thu, Jan 17, 2013 at 11:17:07PM +, Neil Williams wrote:
> On Thu, 17 Jan 2013 21:51:32 +0100
> Wouter Verhelst wrote:
>
> > On Thu, Jan 17, 2013 at 09:34:16AM +0100, Johannes Schauer wrote:
> > > Hi,
> > >
> > > On Thu, Jan 17, 2013 at 08:33:57AM +0100, Wouter Verhelst wrote:
> > > > If w
On Thu, Jan 17, 2013 at 11:34:55PM +0100, Johannes Schauer wrote:
> Hi,
>
> On Thu, Jan 17, 2013 at 09:51:32PM +0100, Wouter Verhelst wrote:
> > > I'm not sure if wanna-build is the right tool to do this
> >
> > Why not?
> >
> > It already needs to do build-dependency tracking, marking packages
On Thu, 17 Jan 2013 21:51:32 +0100
Wouter Verhelst wrote:
> On Thu, Jan 17, 2013 at 09:34:16AM +0100, Johannes Schauer wrote:
> > Hi,
> >
> > On Thu, Jan 17, 2013 at 08:33:57AM +0100, Wouter Verhelst wrote:
> > > If wanna-build is updated to support these two fields, then I imagine
> > > it can
Hi,
On Thu, Jan 17, 2013 at 09:51:32PM +0100, Wouter Verhelst wrote:
> > I'm not sure if wanna-build is the right tool to do this
>
> Why not?
>
> It already needs to do build-dependency tracking, marking packages as
> "can't be built yet because build-depends aren't there yet" all the
> time. T
On Thu, Jan 17, 2013 at 09:34:16AM +0100, Johannes Schauer wrote:
> Hi,
>
> On Thu, Jan 17, 2013 at 08:33:57AM +0100, Wouter Verhelst wrote:
> > If wanna-build is updated to support these two fields, then I imagine
> > it can run the bootstrapping dependency algorithm. While you wouldn't
> > want
On Thu, Jan 17, 2013 at 10:35:03AM +0900, Charles Plessy wrote:
> Le Wed, Jan 16, 2013 at 05:26:52PM +0100, Johannes Schauer a écrit :
> > Whether or not "nocheck" and "nodocs" can/should become build profiles
> > is of course still to be debated.
> for the packages I maintain, I am now replacing
+++ Wouter Verhelst [2013-01-17 08:33 +0100]:
> However, to do that, there's one thing I'm missing in your mail: there
> will be cases where packages, when built in a particular profile do not
> support some functionality. That is, the package is available and does
> most of what the full package
On 17/01/13 01:35, Charles Plessy wrote:
> for the packages I maintain, I am now replacing the regression tests that
> were ran during the build process by autopkgtest test suites.
...
> If this eventually becomes the norm, then we will not need "nocheck" build
> option or profile anymore.
Not nec
On 17/01/13 03:18, Wookey wrote:
> +++ Matthias Klose [2013-01-16 21:09 +0100]:
>> Even if there are a few more, I like it better to make the profiles more
>> granular, and then letting the people doing a bootstrap decide what to
>> include
>> in a stage1 or stage2 build.
>
> I can see some logic
Johannes Schauer email.de> writes:
> Your first example indeed demonstrates why multiple profiles are useful
> to be enabled at once.
Right, wasn’t that the assumption? Profiles are like a bitmask, or
checkboxen. Default is: all are disabled.
> Build-Depends: foo , bar
This is better. No ma
Colin Watson debian.org> writes:
> Also potentially x32.
Which is already on debian-ports, though with no packages at the moment:
http://buildd.debian-ports.org/stats/
Another thing would be a Coldfire port (which Wouter might eventually
start off the m68k port, but we’re concentrating on that
Neil Williams debian.org> writes:
> I'm not sure if we are going to find this situation:
>
> Source: foo
> Build-Depends: bar , baz <+embedded>
(No + there.)
I for one am waiting for this to be accepted for official archive
packages, because I want to use
Build-Depends: …, dietlibc-dev , …
f
* Charles Plessy , 2013-01-17, 10:35:
for the packages I maintain, I am now replacing the regression tests
that were ran during the build process by autopkgtest test suites.
http://dep.debian.net/deps/dep8/
(see http://developer.ubuntu.com/packaging/html/auto-pkg-test.html
while Alio
Hi,
On Thu, Jan 17, 2013 at 08:33:57AM +0100, Wouter Verhelst wrote:
> If wanna-build is updated to support these two fields, then I imagine
> it can run the bootstrapping dependency algorithm. While you wouldn't
> want to upload a package to the debian.org archive when the
> architecture is as ye
Hi Johannes,
On Tue, Jan 15, 2013 at 07:18:40PM +0100, Johannes Schauer wrote:
[...]
> 2. Build-Profiles (extension 1)
> ===
>
> When a source package is built with fewer build dependencies (cross,
> embedded, stage1, nodocs...), then it often happens that it does not
+++ Ian Jackson [2013-01-16 13:50 +]:
> Johannes Schauer writes ("Bootstrappable Debian - proposal of needed
> changes"):
> > 6. Conclusion
> > =
> ...
>
> > - do the proposals for the needed fields sound convincing? Can they be
> &g
+++ Matthias Klose [2013-01-16 21:09 +0100]:
> Am 16.01.2013 17:26, schrieb Johannes Schauer:
> > On Wed, Jan 16, 2013 at 04:00:15PM +0100, Matthias Klose wrote:
> >>
> >> So it does make sense to build with two profiles like stage1 & check.
Yes. I can think of situations where being able to speci
Le Wed, Jan 16, 2013 at 05:26:52PM +0100, Johannes Schauer a écrit :
>
> Whether or not "nocheck" and "nodocs" can/should become build profiles
> is of course still to be debated.
Hi all,
for the packages I maintain, I am now replacing the regression tests that
were ran during the build process
On Wed, Jan 16, 2013 at 06:47:01PM +, Neil Williams wrote:
> A different - similarly strict - criterion would catch out glib2, gtk
> and others- introspection / marshalling code. This can cause a build
> failure but can also cause more difficult bugs which only show at
> runtime. Skipping the e
Am 16.01.2013 17:26, schrieb Johannes Schauer:
> Hi,
>
> On Wed, Jan 16, 2013 at 04:00:15PM +0100, Matthias Klose wrote:
>> this only takes care about packages with a reduced package set built,
>> or packages with reduced functionality. There are same cases missing:
>>
>> - extra build dependenci
On Wed, Jan 16, 2013 at 05:41:31PM +, Colin Watson wrote:
> > If Debian wants to incorporate the ability to being bootstrappable
> > in its policy, then there *must* be some packages which are cross
> > compiled for a minimal build system. Adding this header to those
> > source packages would m
On Wed, 16 Jan 2013 17:55:00 +
Colin Watson wrote:
> On Wed, Jan 16, 2013 at 03:40:52PM +, Neil Williams wrote:
> > On Wed, 16 Jan 2013 13:50:17 +
> > Ian Jackson wrote:
> In my reply I'm going to use autoconf terminology, so host =>
> architecture built for, and target => only relev
On Wed, Jan 16, 2013 at 03:40:52PM +, Neil Williams wrote:
> On Wed, 16 Jan 2013 13:50:17 +
> Ian Jackson wrote:
> > Is it possible that packages might only cross build for certain
> > targets ? Or only for certain hosts ?
In my reply I'm going to use autoconf terminology, so host =>
arc
On Wed, Jan 16, 2013 at 11:52:42AM +0800, Paul Wise wrote:
> That sounds useful, so yes. arm64 is on the way, it would be a nice
> test case but I guess wookey/Sledge are onto that. The SH-5 CPU
> architecture apparently exists but has no port. There are also the
> architectures with open-source CP
On Wed, Jan 16, 2013 at 12:26:53AM +0100, Jakub Wilk wrote:
> 2) Support for the :any qualifiers in Build-Depends was added to apt
> in February 2010, and to dpkg in March 2012; AFAIK it's still not
> supported by wanna-build.
I'm working on the buildd/wanna-build side of things at the moment (lat
On Tue, Jan 15, 2013 at 07:18:40PM +0100, Johannes Schauer wrote:
> Besides bootstrapping, these build profiles could also be used for
> embedded builds, and to allow for changed buil-deps when cross-building.
On a related point, see:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695287
I'v
Hi,
On Wed, Jan 16, 2013 at 04:00:15PM +0100, Matthias Klose wrote:
> this only takes care about packages with a reduced package set built,
> or packages with reduced functionality. There are same cases missing:
>
> - extra build dependencies for cross builds, like for gcc-4.7:
>{gobjc++,gcc
Hi,
On Wed, Jan 16, 2013 at 01:50:17PM +, Ian Jackson wrote:
> > 5. Cross-Builds field
> > =
> >
> > For even further automation and also for quality assurance, we propose
> > another new field for source packages which indicates whether or not
> > this source package is s
On Wed, 16 Jan 2013 13:50:17 +
Ian Jackson wrote:
> > For even further automation and also for quality assurance, we propose
> > another new field for source packages which indicates whether or not
> > this source package is supposed to be cross compilable.
>
> Is it possible that packages m
Am 16.01.2013 14:50, schrieb Ian Jackson:
> * We initially define one scope "profile", for build profiles.
>
>A build profile is an optional variation that can be applied
>to a particular package, for the purpose of reducing the
>build dependencies and/or avoiding the building of unne
Am 15.01.2013 19:18, schrieb Johannes Schauer:
> This mechanism also covers cross-compiler bootstraping. The eglibc, gcc,
> and kernel packages already have the neceassary staged-build info, but
> the build profiles (1.) part is also needed to specifiy the reduced
> build-deps. The cross-toolchain
Am 16.01.2013 13:05, schrieb Neil Williams:
> The main archive only needs to "carry" this extra information without
> needing to act upon it. If dak needs patches to allow-and-ignore the new
> information, that can be done. Most bootstrapping changes are to turn off
> features by not build-dependi
Johannes Schauer writes ("Bootstrappable Debian - proposal of needed changes"):
> the following is an email written by Wookey and myself.
Firstly, I want to say thank you! This seems like excellent work to
me.
> 5. Cross-Builds field
> =
>
> For ev
On Wed, 16 Jan 2013 10:23:37 +0100
Ansgar Burchardt wrote:
> On 01/16/2013 08:56, Neil Williams wrote:
> > On Wed, 16 Jan 2013 00:26:53 +0100
> > Jakub Wilk wrote:
> >> Not only dpkg, but also wanna-build, sbuild, lintian, dak, and who knows
> >> what else...
> >
> > It's about which ones need t
On 01/16/2013 08:56, Neil Williams wrote:
On Wed, 16 Jan 2013 00:26:53 +0100
Jakub Wilk wrote:
Not only dpkg, but also wanna-build, sbuild, lintian, dak, and who knows
what else...
It's about which ones need to change. lintian response rates are not
likely to be a problem - once this gets app
On Wed, 16 Jan 2013 00:26:53 +0100
Jakub Wilk wrote:
> * Johannes Schauer , 2013-01-15, 19:18:
> >Build profiles extend the Build-Depends format with a syntax similar to
> >architecture restrictions but using < and > instead.
> >
> > Build-Depends: huge (>= 1.0) [i386 arm] , tiny
> >
> >The dra
On Wed, Jan 16, 2013 at 12:41 PM, Wookey wrote:
> I intend to send an update mail on the state of this later this week.
Excellent.
> Does asking d-devel for feedback count as news? Having this
> functionality available for packagers would count as news... But I
> agree that telling people about
+++ Paul Wise [2013-01-16 11:52 +0800]:
> That sounds useful, so yes. arm64 is on the way, it would be a nice
> test case but I guess wookey/Sledge are onto that.
I intend to send an update mail on the state of this later this week.
> If you think this might be interesting to announce more wide
Thanks a lot for your work on this! and to everyone else who worked on
or shaped the proposal.
On Wed, Jan 16, 2013 at 2:18 AM, Johannes Schauer wrote:
> - should Debian be bootstrappable in a fully automated fashion? We
>created the algorithms that can allow this to happen, we just need
>
On Wed, Jan 16, 2013 at 08:58:06AM +0900, Charles Plessy wrote:
> Le Tue, Jan 15, 2013 at 07:18:40PM +0100, Johannes Schauer a écrit :
> > The build profile format was proposed by Guillem Jover together with
> > other solutions he presented in this document [7] as part of bug#661538.
> > Build pro
Charles Plessy wrote:
>Le Tue, Jan 15, 2013 at 07:18:40PM +0100, Johannes Schauer a écrit :
>>
>> The build profile format was proposed by Guillem Jover together with
>> other solutions he presented in this document [7] as part of bug#661538.
>> Build profiles extend the Build-Depends format with
Le Tue, Jan 15, 2013 at 07:18:40PM +0100, Johannes Schauer a écrit :
>
> The build profile format was proposed by Guillem Jover together with
> other solutions he presented in this document [7] as part of bug#661538.
> Build profiles extend the Build-Depends format with a syntax similar to
> archi
* Johannes Schauer , 2013-01-15, 19:18:
Build profiles extend the Build-Depends format with a syntax similar to
architecture restrictions but using < and > instead.
Build-Depends: huge (>= 1.0) [i386 arm] , tiny
[...]
The drawback of this syntax is that Build-Dep parsing tools need to be
Hi,
the following is an email written by Wookey and myself.
0. Introduction
===
The Debian bootstrap build ordering tool Google Summer of Code project
[1] was continued even after the summer ended and recently reached a new
milestone by being able to create a final build order from a
54 matches
Mail list logo
