ople.debian.org/~ema/cargo/. I can work on armel next. The
> tests are green but maybe there's some more meaningful validation we can
> do before uploading? Anyone from debian-rust has ideas or comments?
>
--
Steve Langasek Give
On Tue, Aug 29, 2023 at 02:38:20PM +0200, Rainer Dorsch wrote:
> Am Dienstag, 15. August 2023, 21:31:50 CEST schrieb Steve Langasek:
> > > How about alerting end-user that "did you know your interface name
> > > will change after the reboot thus possibly breaking your n
On Mon, Aug 14, 2023 at 08:02:32AM +0300, Reco wrote:
> On Sun, Aug 13, 2023 at 04:53:13PM -0500, Steve Langasek wrote:
> > On Fri, Aug 04, 2023 at 10:55:44AM +0300, Reco wrote:
> > > On Fri, Aug 04, 2023 at 08:55:21AM +0200, Rainer Dorsch wrote:
> > &g
th0
> Enjoy your (un)Predictable Interface Names.
> Try adding "net.ifnames=0" to kernel's commandline.
They're perfectly predictable, they're just not backwards-compatible.
Forcing systems to use the legacy naming scheme to avoid the transition is
short-sighted.
On Fri, Apr 14, 2023 at 08:58:55PM -0700, Steve Langasek wrote:
> Sorry for the long radio silence on this; I had identified some issues with
> my prior report and wanted to rerun it with some fixes, and that analysis
> took rather longer than expected (mainly due to infrastructure
On Wed, Feb 15, 2023 at 05:08:40PM +, Wookey wrote:
> On 2023-02-04 21:42 -0800, Steve Langasek wrote:
> > On Thu, Oct 20, 2022 at 09:42:58PM -0700, Steve Langasek wrote:
> > > This is good. One thing that I think has been missing from the discussion
> > > about ar
failures?
On Tue, Mar 21, 2023 at 03:00:41AM +, Wookey wrote:
> On 2023-02-15 17:08 +, Wookey wrote:
> > On 2023-02-04 21:42 -0800, Steve Langasek wrote:
> >
> > Yes I think we should proceed with this analysis on debian to get a
> > better handle on just how
On Thu, Oct 20, 2022 at 09:42:58PM -0700, Steve Langasek wrote:
> This is good. One thing that I think has been missing from the discussion
> about armhf rebootstrap is the fact that we do have experience in Debian
> doing cross-cutting ABI transitions without having to change an
>
adays, I wonder if abi-compliance-checker would be usable for analyzing
the ABIs of C libraries to accurately identify what needs to change for
time64_t. I think it would be interesting to know from this how many shared
libraries expose time_t size in their ABIs.
--
Steve Langasek
GS having been a priority for Debian as far
back as 2003, I think it was no more than 5 years ago that I was still
finding libraries in the archive that were incompatible with LFS because
they were leaking 32-bit types into their own ABIs. I think the lesson to
be learned from 64-bit file support is t
> > in the meantime, can we do a giveback on armhf to a machine other than
> > arm-arm-01 to make sure that the latest knot-resolver does actually
> > build?
> >
> > thanks for your work on keeping armhf in good shape in debian,
> >
> >
On Wed, Nov 28, 2018 at 11:46:21PM +0200, Adrian Bunk wrote:
> On Tue, Nov 27, 2018 at 02:06:27PM -0800, Steve Langasek wrote:
> >...
> > Hmm, so I'm not sure this reflects the actual state of the art wrt dual Qt
> > stacks as it existed in Ubuntu at the time
On Wed, Nov 28, 2018 at 05:03:51PM +0300, Dmitry Shachnev wrote:
> On Tue, Nov 27, 2018 at 11:00:52PM -0800, Steve Langasek wrote:
> The amount of packages will probably be larger in the current sid,
> but it should not be more than 20 packages.
> Plus there are packages whi
f analysis as above, so
anyone interested in doing this in Debian can reasonably work out the scope.
And each of those gles source packages is a purely mechanical transformation
of the base Qt source package.
So perhaps someone in this thread is willing to put in this effort to
maintain 6 source
required to do this analysis, but relatively
little human time.
If someone was interested in volunteering to ensure both GL and GLES were
supported by Qt, this is where I would suggest they start, in order to
accurately size the effort involved and know what they're signing up for.
--
me across to me in
your mail, sorry. If you still think it is too much maintenance overhead to
provide a dual stack for these 5 libraries (plus any others that later start
to use GL-dependant ABIs), I think you're absolutely entitled to that view.
--
Steve Langasek Give m
On Mon, Nov 26, 2018 at 03:39:03PM -0800, Keith Packard wrote:
> Steve Langasek writes:
> > Long ago I heard rumors of development work on mesa that would allow it to
> > function as a proxy library, so that apps would link against libGL as needed
> > and the GL imple
gt; > *But* we are open to change this for any arch (read it: support either one
> > or
> > the other technology) as long as the decision is taken by the technical
> > committee. As I wrote before, we will keep the status quo, so if anyone is
> > interested in any cha
ccess on armhf, the reason they don't all do this is that the fixups are
expensive and it's better to fix the code.
(I am somewhat surprised to see that this particular package build is an
armhf build on an "armel" host; but I'm not sure that's material here.)
--
Steve La
terate over all of the dtbs for the current kernel and copy them around.
But I think we're even farther from having any kind of standard
boot.scr/uEnv.txt infrastructure that would cope with this, than we are from
having dtbs themselves as a standard interface.
--
Steve Langasek
e of that thread, I recall that the proposed standardization of
dtb locations was mostly not useful for the platforms I cared about because
they were going to be placed in locations that wouldn't help u-boot find
them in order to pass them to the kernel.
--
Steve Langasek
portland/u-boot/tree/2014.04-cubox-i-support
I suppose if you've got 2014.07-rc4 in experimental now, that implies you've
forward-ported the patches and I should have a look at providing updated
branches.
--
Steve Langasek Give me a lever long enough and a Free
s shouldn't be done
> before the jessie release.
However, bumping the CPU requirements for the armel port to armv7 also make
that port completely redundant; at that point it's just a slow armhf with no
advantages.
--
Steve Langasek Give me a lever long enough and a Free O
"/boot /"; in some cases
this will give an extra directory lookup, but it should never cause the
bootloader to get confused by stray files in /boot vs. / on the root
filesystem.
--
Steve Langasek Give me a lever long enough and a Free OS
DIR/$usname"
mkimage_script "$usaddr" "boot script"
"$boot_script" \
"$tmpdir/boot.scr"
boot_script="$tmpdir/boot.scr"
; urgency=medium
* Add support for the CuBox-i.
+ * Add support for symlinking kernels/initrds on targets that use dtb.
-- Steve Langasek Fri, 30 May 2014 16:23:29 +0200
diff --git a/functions b/functions
index 9213145..d3009e8 100644
--- a/functions
+++ b/functions
@@ -631,14 +631,15 @@ case
ebian/changelog
index 3fcba0a..09efe83 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+flash-kernel (3.20) UNRELEASED; urgency=medium
+
+ * Add support for the CuBox-i.
+
+ -- Steve Langasek Fri, 30 May 2014 16:23:29 +0200
+
flash-kernel (3.19) unstable; urgency=low
* Su
> Can we get the patch on the list for comment please? Looks like it might
> want rebasing onto later flash-kernel?
Ok. Here's a pair of patches for consideration. I've rebased so that they
apply cleanly, but am away from my box and haven't verified yet that current
flash-kernel works with these
On Fri, May 30, 2014 at 04:07:10PM +0200, Rainer Dorsch wrote:
> Am 30.05.2014 15:04, schrieb Ian Campbell:
> >On Fri, 2014-05-30 at 14:13 +0200, Steve Langasek wrote:
> >>There is already a branch for this in flash-kernel git, which I was waiting
> >>for u-boot su
branch for this in flash-kernel git, which I was waiting
for u-boot support on in unstable before proposing for merge. U-Boot
support is there now, so maybe this is mergeable now. Ian, would you like a
bug report for this?
git://git.debian.org/d-i/flash-kernel.git cubox-i
--
Steve Langasek
poster is trying to boot without an
> > initramfs... (no mention of an initramfs in the pastebin...)
> That wouldn't matter, from linux-image-3.13-1-armmp_3.13.10-1_armhf.deb
> # CONFIG_TI_EDMA is not set
> Sorry, can't confirm if it actually works as an external module.
Ok. So
nel+dtb+initramfs not allow this driver to be dynamically loaded for the
hardware where it's needed?
OTOH, maybe the problem is the poster is trying to boot without an
initramfs... (no mention of an initramfs in the pastebin...)
--
Steve Langasek Give me a lever long
iven that qantenna has always required GLU, and is unsupportable now
because GLU is not usable with Qt5 on arm*, I think this is the right thing
to do.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it
ved in getting the porters access to
porter boxes? Porter boxes exist so that DDs *not* involved in a port have
access to a machine of the architecture and can keep their packages working.
I've never heard of a porter who didn't have access to their own box
Black
> http://cubieboard.org/
There's no reason to run raspbian on either of these, that would be an
anti-optimization. Both of these boards use new enough chips to run Debian
armhf.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
> supported anymore or is it still supported? If so, is this userdevfs
> really useful?
I've never even heard of an ADS board. Whatever it is, I think it's clear
that the support can be killed off now.
--
Steve Langasek Give me a lever long enough and a Free OS
On Sat, Apr 27, 2013 at 09:32:59AM +0200, Peter Palfrader wrote:
> On Fri, 26 Apr 2013, Steve Langasek wrote:
> > On Fri, Apr 26, 2013 at 02:49:05PM +0200, Hector Oron wrote:
> > > Thanks, that is a very kind offer and with ARM hat on, we cannot
> > > reject
to does imply some logistical
challenges for ensuring that we continue to have good kernel support during
the development cycle, so that release+1 will be supportable on the box.
But this is a problem we've dealt with before, and certainly in this case
the upstream kernel support is quite good
s had a VFP unit,
> but that forward path is easy.
> It seems a net win compared to a few % extra speed in FPU-intensive
> apps on v7+ CPUs.
The v7+ CPUs far outnumber the v6 CPUs, of which there's only one platform
that anyone is interested in (the RPi). Amortizing that few % spee
ebian.org/250468)
> So it was not by choice that Debian dropped i386.
It was dropped by the unanimous decision of every developer in Debian to not
fix the security bug in the i386 emulation patch.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
. How are you invoking the program? Have you cross-installed
libc6:armel for compatibility, or done something else here?
The key requirement for successfully running armel binaries on armhf is to
have an ELF PI (ld.so) that can tell the difference between hard-float and
soft-float libraries on the syste
OS classes.
There's a particular reason why this is true for armel vs. armhf. The
difference between armel and armhf ABIs lies entirely in the calling
convention when using floating point arguments, and there are no syscalls
that take floating point arguments, let alone using floating po
On Thu, Nov 10, 2011 at 12:30:09AM +0100, Mike Hommey wrote:
> reassign 648233 release.debian.org
> thanks
> nmu libxau_1:1.0.6-4 . armel . -m "Rebuild for armv4t"
> nmu libxcb_1.7-4 . armel . -m "Rebuild for armv4t"
Scheduled. Sorry about that.
--
Steve Lang
ocess. If this can be sanely togglable on ARM at
runtime, it would be keen to use the same interface on this arch.
HTH,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
;scheduled centrally by the wanna-build admins.
> Is there such a central authority for ports on debian-ports.org or only
> for the architectures in the official archive?
I'm not sure, to be honest.
--
Steve Langasek Give me a lever long enough and a F
7;s no need to email port mailing lists to request binNMUs, these are
scheduled centrally by the wanna-build admins.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ub
'arm' port) is binary-compatible with the Debian armel
port, it is *not* binary-compatible with the armhf port; the minimum
supported hardware for armel is different between Debian and Ubuntu, but
then, this is true of the i386 port also; and Linaro doesn't have any
"ports"
idiv
49ec gDF .text GCC_3.5 __aeabi_uldivmod
5ec0 gDF .text 0528 GCC_4.0.0 __divsc3
49d0 gDF .text GCC_3.5 __aeabi_ldivmod
$
Probably? :)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
t takes longer. (Multiarch in
> general is an example of this).
I don't see either of these to be technically better or worse. The fact is
that we are going to *have* to document multiple points where our directory
strings do not follow naturally from the existing array of GNU triplets; and
tha
n. If we instead make it the problem of
the cross-compiling developer to ensure their toolchain has the right
defaults for their target architecture, we don't need to worry about package
disruption at all... we just have to worry about people using the wrong
toolchain settings for t
lease. If we can (collectively) get our decision made on
the path selection *now*, that's achievable - and we can be rid of ia32-libs
from Debian (unstable) and Ubuntu within a year, and we can bring armhf up
as the first multiarch-from-the-start port in Debian. If we instead
would like to see this
> better addressed in Linaro and/or upstream.
I'm not sure how Linaro could better address this, short of persuading
upstream to allocate a separate triplet for armhf - which has been
explicitly refused on the upstream mailing list. Do you have something else
in
ta
in the long term - which is why the (right) goal is to merge the armhf work
into Debian so that there *isn't* a delta.
Bitbake doesn't help with that goal; the only way to help that goal is to
have the sometimes-difficult conversations with the Debian maintainers that
let us arrive
for discussion in Debian? Should I bring 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?
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
De
al for wheezy.
(Note, however, that historically porters have been given a very free hand
with shorter-than-usual waiting periods for NMUs. I think you will find
your reception among maintainers *better* if you file these bugs at
important and NMU for them, than if you bump them to serious. :)
--
Steve
ssible
nested build-dep loops. I'm sure Loïc would welcome input on refining the
design, not to mention help implementing Debian buildd infrastructure.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I
oving libglitz is more painful than it would be otherwise,
because instead of just rebuilding cairo itself without glitz, you must
rebuild everything above cairo in the stack that used pkg-config for
linking.
I don't argue that this makes --as-needed *correct* as a default
y.
So even if you persuaded the upstream toolchain folks to specify a new
triplet for armhf after all, I think we should still go ahead with a
separate name mapping table for multiarch.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
ian ARM that they could
grant you access to. :)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga..
On Mon, Jul 19, 2010 at 07:02:32PM +0100, Hector Oron wrote:
> 2010/7/18 Steve Langasek :
> > I'm puzzled why dpkg needs a unique triplet for a port. dpkg needs to map
> > port names to triplets, but why does it need to do the inverse? And if it
> > doesn't need
plet, perhaps there are official names
for the ELF architectures that can be used - that can be determined without
too much hard-coding all over the place?
(BTW... if you want to run both armel and armhf under multiarch... which
package's libc gets to own ld.so? :P)
--
Steve Langasek
t should be short and
> not try to encode too much information in it.
> > I would be a bit scared that this has a chance of getting out of date,
> we have i386 port and nobody has an issue with 2 decades old name.
Nah, people have issues with it, but backwards-compatibility
On Thu, May 13, 2010 at 06:03:39AM -0400, Michael Casadevall wrote:
> Binary objects for i386 won't work on ARM, there's no chance of getting the
> Brother drivers working directly
Multiarch multiarch multiarch.
(qemu.)
--
Steve Langasek Give me a lever long e
> There's also a warning from dpkg-architecture which I don't really
> understand.
> dpkg-architecture: warning: Specified GNU system type
> arm-linux-gnueabi does not match gcc system type i486-linux-gnu.
That warning is output whenever dpkg-architecture is calle
ee
of a 4-byte alignment on i386 either; we started seeing lots of failures
because of a 2-byte alignment being used in practice.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Develope
On Fri, Sep 25, 2009 at 06:06:35PM +0100, Martin Michlmayr wrote:
> * Steve Langasek [2009-09-22 23:28]:
> > After building myself a 2.6.30 kernel with the iop dma patches for my
> > Thecus,
> > I started seeing reproducible kernel oopses on large NFS transfers, such as
call
down_read(¤t->mm->mmap_sem) if in_atomic() is true. Updating the dma1
patch from http://people.debian.org/~tbm/dma/dma-patch to the attached
appears to have fixed the problem for me, giving me a stable DMA-enabled
squeeze kernel.
Cheers,
--
Steve Langasek Give me a
le.
Even if there's not a library transition, a targetted backport fix would be
greatly preferred from a release standpoint.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROT
t want
to deal with the security implications of lots of shell access. The
'netwinder' buildd is hosted by Bdale Garbee, though; maybe he could give
Paolo access to that one?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
to netwinder, there's probably no sense in treating this as
release-critical.
But does anyone understand yet *why* this bug affects the netwinders and not
the cats boxes?
> Removing mono from arm for this release entirely seems worse than
> having a version which does work on some(?)/mo
port on netwinder is RC in the porters' estimation, and there is a
porter with the know-how and time to fix this bug who is volunteering to
have me nag them once every other day until it's fixed ;)
If we are still missing information for the porters to decide whether this
should be RC
r of the
autobuilders is probably not a great idea.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBSCRIBE, e
set level between the
netwinder and cats systems? The mono build failures are very consistent in
happening only on the netwinder systems AFAICS, and I'm pretty sure that
there isn't a kernel difference between the two groups of autobuilders that
would account for it.
--
Steve Langasek
I want to confirm: do the ARM porters consider this reasonable?
Should support for arm v3 systems be considered release-critical on this
architecture? And if so, is someone available to work on fixing mono's code
generation, or would mono need to be dropped from arm for etch?
Thanks,
--
better for the arm and m68k porters to work together to
identify a subset of the archive that's appropriate for embedded systems,
instead of struggling with and failing to meet the current standards? Hmm,
then again, one of the 28 arm uninstallables in testing right now is
"contacts", which se
and much chance of being included in the etch release without rapid
improvement.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www
On Mon, Aug 28, 2006 at 10:15:41PM +0200, Mike Hommey wrote:
> On Mon, Aug 28, 2006 at 01:01:00PM -0700, Steve Langasek <[EMAIL PROTECTED]>
> wrote:
> > Yes, it can be and is configured by source package. If you can get some
> > numbers to the buildd admin (James) about
ildd admin (James) about how long it should take for these
packages to build, it should be straightforward to fix up that config AFAIK.
Does anyone know what happened to make ld so much slower on arm all of a
sudden?
> Anyways, a manual binNMU forcing the use of ecj-bootstrap 3.1.2-6 should
/docs/libs'
[...]
A full build log can be found at
<http://buildd.debian.org/fetch.php?pkg=gst-plugins-base0.10&arch=arm&ver=0.10.9-1&stamp=1153184849&file=log>.
Some of the errors suggest the problem may be linked to arm's unique FP
handling. Please consult the debi
Hi all,
Would someone be willing to look into doing porter NMUs of the non-free
xmame package on arm/mips/s390? Updates are needed on these architectures
to get an RC bugfix into testing for the package.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
chitecture that they can be working on in between getting things back in
line with the release arch standards. As always, porter NMUs are encouraged
-- you don't need an RC bug as an excuse to fix a package for your
architecture! Wouldn't it be great to have zero bugs on that page
ad to use g++-3.4 on arm/hppa/m68k.
> turqstat
> 28 days old
> missing hppa build
> blocked by gcc-4.0/gmp
Also blocked by qt...
> xloadimage
> too young
> blocked by libpng hich is missing an arm build
Should actually be rebuilt on
On Fri, Jun 24, 2005 at 08:40:42AM -0400, Lennart Sorensen wrote:
> On Fri, Jun 24, 2005 at 02:29:19AM -0700, Steve Langasek wrote:
> > So are there any porters alive out there on debian-arm? Being unable to use
> > cp, mv, and install after upgrading from woody to sarge is a
least
document this in the release notes if we need to.
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
on kernels lacking any ACL kernel
support whatsoever -- this architecture-specific failure more likely points
to a kernel ABI issue specific to ARM.
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
refers testing
> APT policy: (500, 'testing')
> Architecture: arm (armv4l)
> Kernel: Linux 2.4.18-rmk7
Do you know if upgrading to the 2.4 kernel version available in sarge makes
a difference here?
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
> make: dh_testdir: Command not found
> make: *** [clean] Error 127
> The newer version in sid does not have this problem.
Non-free package, needs builds on arm and s390 to get the update into
testing. Volunteers?
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
g
to be supported.
At the very least, soliciting builds for the package on archs where it's
never been built -- and never been missed -- seems like it will just
make it harder for you to maintain the package. I know most maintainers
I hear talking about mipsel wish they had the *option*
andle modules from alien architectures. If you can figure this
one out, I suspect the rest of the actual d-i build would be fairly
simple to fix up for cross-building.
Cheers,
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
Build queue.
HTH,
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
Could someone re-queue uw-imap for building on arm, s390, and hppa? The
first build attempt failed on these archs due to a now-fixed bug in
po-debconf (214397).
Thanks,
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
, if the VM is fully virtual, it should be relatively easy to
support all Linux architectures by generalizing your existing support --
the only major variables are word size and endianness..
HTH,
Steve Langasek
postmodern programmer
pgpWOWDP0yJGE.pgp
Description: PGP signature
ing for the
current status of php4 on arm. I.e., it's purportedly being built as we
speak. So as long as woody isn't released before April, it should make
it in with no problems. ;)
Steve Langasek
postmodern programmer
pgpO4AcH8WAg2.pgp
Description: PGP signature
four potato archs could rebuild the package as well.
TIA,
Steve Langasek
postmodern programmer
pgp7mH3mvLP7R.pgp
Description: PGP signature
94 matches
Mail list logo
