hich could let it work in the future.
> 'dpkg --unpack and dpkg --root foo --install' insist on trying to run
> the prerm/preinst which is just wrong.
Agreed (as things currently stand, and this will remain the case until we
have a robust method to run the right things in the right
ring this up on the
> debian-embedded list? Are there other stakeholders who would have input
> regarding the array of available uclibc ABIs and how to specify these?
Debian-embedded contains people who know about uclibc stuff. (ron,
Bernard Link, virtuoso, Simon richter)
Comments
on, because I
> don't really see the point in the multiarch tuples, when the GNU triplets
> seems to do the job just fine (modulo the armhf and i386 issues, which we
> should just fix).
This pretty-much boils down the issue. dpkg needs to use a unique and
reliable internal represent
ion to this problem
than inventing a new set; and in general Debian likes to go for the
technically-best solutions even if it takes longer. (Multiarch in
general is an example of this).
However, equally, it's taken a really long time to get this far, and
if we made a reasona
ed at 3.7Mb (what _were_ you thinking hector? :-)
I've put them here:
http://wookware.org/files/build-reverse-cross.log.txt
http://wookware.org/files/build-reverse-cross-no-biarch.log.txt
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
--
To
ap3.patch
( A better patch to reduce the ridiculous list of static field names
will be along soon, but that's not finished - just close your eyes and
ignore that bit)
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
--
To UNSUBSCRIBE, em
writing up my
analysis of the options. I expect to have some fruitful discussion on
this subject at debconf so we can do further work with something
everyone is happy with.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
--
To UNSUBSCRIBE, ema
like should live, but I don't currently see good arguments to put any
more of it into dpkg.
If we are agreed on that then this bug is indeed closed.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-dpkg-requ..
likely to be the case the cross-compiler needs so different flags to
the more capable native toolchain.
Any ideas?
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject
work quite well and not get in other
people's way. I would like to have a more general and convincing
long-term plan. I'll carry on trying to work that up. It is a
good subject for a 'cross-build sprint'.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard
+++ Colin Watson [2013-01-08 15:23 +]:
> On Wed, Nov 14, 2012 at 12:08:26PM +0000, Wookey wrote:
> > Following on from discussion in this thread
> > http://lists.debian.org/debian-embedded/2012/06/msg00030.html
> >
> > The cross-build-essential package has b
it doesn't already, because it'll
need to soon. I am of course happy to hear of reasons why that will
break things and we should not do it yet.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-d
and other outstanding issues such as
cross gobject-introspection. We've experimented on most of this in
Ubuntu with armhf and arm64 so (a select few of us) have a reasonable
idea of how it should work, but that knowledge now needs formalising
and documenting, and outstanding questions
that might make one conservative about this is that we
don't yet have a solution to the 'perl-module' problem of transitive
arch-dependencies (XS-module -> arch:all module -> XS module), but I
can't actually see why the above change would impede solutions to the
latter.
So I think I am suggesting that the entry "We propose that literals of
different namespaces can be mixed within a disjunction. Therefore, the
following would be legal:
Build-Depends foo [arch.i386 !profile.cross]"
Is changed to say that you can't do that, and have to do [i386]
[!
ample.
We're absolutely fine with the <> syntax, which is already implemented
(and to be honest I prefer the look of it in practice). Are you
proposing pkg as opposed to pkg ?
We can adjust the patches for that if so.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboa
+++ Guillem Jover [2013-08-16 14:15 +0200]:
> Hi!
>
> On Fri, 2013-08-16 at 02:59:45 +0100, Wookey wrote:
> > In the interests of making some progress, I suggest that we simply say
> > that arches and profiles can't be mixed in a [], as otherwise we'd
> > ha
+++ Guillem Jover [2013-10-21 07:31 +0200]:
> Hi,
>
> On Tue, 2013-09-17 at 12:31:17 +0200, Johannes Schauer wrote:
> > To get this issue moving, I have attached a patch which implements the <>
> > version of the proposal. The patch is based upon one by wookey and pe
as one but I added autotools-dev to get its autofoo up
to date. Clearly things that can't cope with this state are buggy.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debi
+++ Niels Thykier [2014-11-04 07:10 +0100]:
> On 2014-11-04 03:58, Wookey wrote:
> > +++ Niels Thykier [2014-10-22 20:25 +0200]:
> >> [...]
> >> In particular, it is not clear to me whether (e.g.) "pkg:$arch"
> >> implies "pkg:any" or/a
ecture. If there really is a meaningful difference between
> architectures a reverse-dependency could observe, perhaps bar should be
> M-A: allowed instead…
That seems reasonable to me.
Would some kind of multiarch session at debconf be useful to have
higher-bandwidth discussion on t
+++ David Kalnischkies [2015-04-17 11:27 +0200]:
> I never even considered that another way of interpreting it might exist
> until my nose got rubbed in it yesterday….
Sorry - meant to ask: What was the case/bug/conversation that brought this up?
Wookey
--
Principal hats: Linaro,
session at debconf for such discussion on the
off-chance that definitive conclusions have not been reached
beforehand (or we don't actually agree). I'm hoping that all of you,
Guillem and David might be in attendance? (as well as others that have
taken aqn interest in multiarch).
Wookey
--
Prin
.
Anyway, what's the bug? Are packages that won't build with
"dpkg-buildpackage -j4" buggy, or is it a bug that man pages suggest
using "dpkg-buildpackage -j4" rather than
"DEB_BUILD_OPTIONS=par
t;
> > The full documentation for make is maintained as a Texinfo manual. If
> > the info and make programs are properly installed at your site, the
> > command
> >
> > info make
> >
> > should give you access to the complete manual.
vn/gcccvs/branches/sid/gcc-defaults
> E: Unable to find a source package for version
The 'gcc' binary package is built from the gcc-defaults source package. This is
a metapackage.
The compiler itself (lots of binary packages) is built from the gcc-4.9 source
package.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
done by engaging further. Yes it
will be hard work, but if it's not done we are just stuck.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
. A simple example whch dies is nmap (running
i686-w64-mingw32-gcc ).
Given that dpkg-buildflags does this right (with my patch):
DEB_HOST_ARCH=amd64 dpkg-buildflags --get CFLAGS
-g -O2 -ffile-prefix-map=/home/wookey/packages/dpkg-1.21.8=.
-fstack-protector-strong -Wformat -Werror=format-security
D
On 2022-06-04 06:25 +0200, Guillem Jover wrote:
> On Sun, 2022-05-29 at 14:19:05 +0100, Wookey wrote:
> > Discussion:
>
> > The -mbranch-protection=standard option could be set either by dpkg or
> > by gcc. I'm not quite sure how we decide which is most appropriate?
&
On 2023-05-03 21:50 +0100, Steve McIntyre wrote:
> If we're still seeing
> issues in packages today, then maybe we might find some help from
> Wookey or Emmanuel (who should both be reading this list!).
I am, and have noticed this issue and put it on our list of things to look
at.
uld be applied to tidying up stuff like this which is simply no
longer in use. If/when 'arm' is removed 'armeb' should certainly go
with it.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
ed rebuild to see how much of a problem
we really have, and then decide if we should revert it too until some
stuff if fixed. We should have a better idea of whether to go back or
forward farily soon. I look forward to some more details on what
actually broke (other than valgrind) so
o-one has shown much
interest in fixing it over the last decade or so. Providing the
symlinks at least shouldn't be very hard?
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
chive had
> migrated away from `fakeroot`).
>
> 2) A quick fix to `debhelper` to remove the reliance on
> `fakeroot` when assembling `-dbgsym` packages.
A detail, I know, but we take detail-correction seriously round here. :-)
Wookey
--
Principal hats: Debian, Wookwar
34 matches
Mail list logo
