Jakub Wilk writes ("Re: assumptions about the build environment."):
> More questions about build env assumptions:
My answers:
> Can you assume that /sbin and /usr/sbin are within PATH?
No. Package builds are supposed to be done as the user; the rootness
of the "install&quo
On Sun, Oct 07, 2012 at 11:54:40AM +0200, Eric Valette wrote:
> I'm currently trying to compile armhf package for the rasberry pi on
> a amd64 machine and naively though it would be easy to do with
> multiarch. I screwed my machines(replaced the dynamic linkers, ftp
> and other tools by arm binarie
On Sun, Oct 07, 2012 at 10:58:31AM +0200, Jakub Wilk wrote:
> More questions about build env assumptions:
>
> Can you assume that /sbin and /usr/sbin are within PATH?
At which point(s) during the build?
For sbuild:
During any command run as the build user (*not* root), it will
default to
m
While working on debian one thing I have not managed to find is
documentation on what packages can and can't assume about the build
environment. Does such documentation exist and if not should it be
created.
Some specific cases i'm wondering about:
I just discovered that on my beagleboard XM (un
More questions about build env assumptions:
Can you assume that /sbin and /usr/sbin are within PATH?
Can you assume that the SHELL environment variable (_not_ the makefile
variable) is set to something §10.4-compliant?
(My personal answers to these questions are: no and no.)
--
Jakub Wilk
On Thu, Sep 27, 2012 at 01:14:49PM +0100, Wookey wrote:
> In general I'm in favour of agreeing what can be relied upon and
> then only providing that in buildds. But you are quite right that for
> the purposes of buildds doing native building this improves your
> success rate by glossing over poten
On Thu, 2012-09-27 at 13:14:49 +0100, Wookey wrote:
> But the case of uname _is_ easy to deal with - use dpkg-architecture.
Well, not really if the patch is supposed to go upstream, given that
dpkg-architecture is not a distribution-neutral interface.
In most of the cases uname is wrong because
+++ Wouter Verhelst [2012-09-24 13:14 +0200]:
> On Sat, Sep 22, 2012 at 07:06:57PM +0200, Adam Borowski wrote:
> >
> > That it breaks multiarch builds.
>
> Multiarch builds are not done on our buildd machines.
Yet. They very likely will be soon, for partial architectures and
cross-toolchains.
A
Wouter Verhelst (24/09/2012):
> On Sat, Sep 22, 2012 at 07:06:57PM +0200, Adam Borowski wrote:
> > You'd need a separate chroot for every arch you want to be able to
> > compile for.
>
> Buildd machines typically have only one chroot for each distribution
> they build, as they don't build for mul
On Sat, Sep 22, 2012 at 07:06:57PM +0200, Adam Borowski wrote:
> On Sat, Sep 22, 2012 at 04:28:32PM +0200, Wouter Verhelst wrote:
> > On Sat, Sep 22, 2012 at 12:23:36AM +0200, Kurt Roeckx wrote:
> > > They probably should try to use the output of dpkg-architecture to
> > > select the arch. Then sh
On Sat, 22 Sep 2012 19:06:57 +0200, Adam Borowski wrote:
> And an interesting tidbit:
>checking for suffix of executables... .exe
>checking whether we are cross-compiling... no
>
> So the concept of "cross-compiling" is pretty fuzzy :)
That typically happens if you have wine and binfmt-s
On Sat, Sep 22, 2012 at 04:28:32PM +0200, Wouter Verhelst wrote:
> On Sat, Sep 22, 2012 at 12:23:36AM +0200, Kurt Roeckx wrote:
> > They probably should try to use the output of dpkg-architecture to
> > select the arch. Then should never check that output of uname -m.
>
> That's living on the ass
On Sat, Sep 22, 2012 at 12:23:36AM +0200, Kurt Roeckx wrote:
> On Fri, Sep 21, 2012 at 08:26:24PM +0100, peter green wrote:
> > Some time ago I found that a package (I think it was openjdk but I
> > don't remember for sure) which relied on uname -r such that linux32
> > had to be used to build it i
On Fri, 2012-09-21 at 23:06 +0200, Adam Borowski wrote:
> On Fri, Sep 21, 2012 at 09:07:57PM +0100, Ben Hutchings wrote:
> > On Fri, Sep 21, 2012 at 08:26:24PM +0100, peter green wrote:
> > > Some time ago I found that a package (I think it was openjdk but I
> > > don't remember for sure) which rel
On Sat, 2012-09-22 at 01:25 +0200, Bernhard R. Link wrote:
> * peter green [120921 21:26]:
> > I just discovered that on my beagleboard XM (under armhf sid) nacl
> > (which previously build on a debian experimental armhf buildd but
> > not a debian unstable armhf buildd) will build if /sys is moun
Package: debian-policy
Severity: whishlist
Version: 3.9.4.0
X-Debbugs-CC: debian-devel@lists.debian.org
Le Sat, Sep 22, 2012 at 12:23:36AM +0200, Kurt Roeckx a écrit :
>
> I think it would also be a good idea to have this documented in
> policy if it's not already.
I totally agree. I created a
* peter green [120921 21:26]:
> I just discovered that on my beagleboard XM (under armhf sid) nacl
> (which previously build on a debian experimental armhf buildd but
> not a debian unstable armhf buildd) will build if /sys is mounted
> but will not build if it is not mounted. Can packages assume
On Fri, Sep 21, 2012 at 08:26:24PM +0100, peter green wrote:
> While working on debian one thing I have not managed to find is
> documentation on what packages can and can't assume about the build
> environment. Does such documentation exist and if not should it be
> created.
One thing that is at
On Fri, Sep 21, 2012 at 08:26:24PM +0100, peter green wrote:
> I just discovered that on my beagleboard XM (under armhf sid) nacl
> (which previously build on a debian experimental armhf buildd but
> not a debian unstable armhf buildd) will build if /sys is mounted
> but will not build if it is not
On Fri, Sep 21, 2012 at 09:07:57PM +0100, Ben Hutchings wrote:
> On Fri, Sep 21, 2012 at 08:26:24PM +0100, peter green wrote:
> > Some time ago I found that a package (I think it was openjdk but I
> > don't remember for sure) which relied on uname -r such that linux32
> > had to be used to build it
On Fri, Sep 21, 2012 at 08:26:24PM +0100, peter green wrote:
> While working on debian one thing I have not managed to find is
> documentation on what packages can and can't assume about the build
> environment. Does such documentation exist and if not should it be
> created.
>
> Some specific cas
peter green wrote:
Some time ago I found that a package (I think it was openjdk but I
don't remember for sure) which relied on uname -r
sorry I meam -m not -r
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.de
While working on debian one thing I have not managed to find is
documentation on what packages can and can't assume about the build
environment. Does such documentation exist and if not should it be created.
Some specific cases i'm wondering about:
I just discovered that on my beagleboard XM (
23 matches
Mail list logo
