o/. 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 me a lever long enough and a
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.
--
Steve Langa
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
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 many libraries we ar
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
>
le 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 Give me a lever long enough
ving 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 that t
make sure that the latest knot-resolver does actually
> > build?
> >
> > thanks for your work on keeping armhf in good shape in debian,
> >
> >--dkg
>
>
>
> --
> Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
>
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 Ubunt
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
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 packages, in order to avoid having to make a choice
between GL and GLES on arm6
d 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.
--
Steve Langasek
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 me a lever long enough and a Free OS
Debian Developer
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 imp
e 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 change feel free to contact the TC.
&g
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 Langasek Give me a lever
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 Give me a lever long enough and a Free OS
Debian Developer to set
boot.scr/uEnv.txt infrastructure that would cope with this, than we are from
having dtbs themselves as a standard interface.
--
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
/vorlonofportland/u-boot/tree/2014.04-imx6-SPL-support
https://github.com/vorlonofportland/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
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
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp
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 Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move
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 support on in unstable before proposing
/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 vor...@debian.org Fri, 30 May 2014 16:23:29 +0200
+
flash-kernel (3.19) unstable; urgency
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
; urgency=medium
* Add support for the CuBox-i.
+ * Add support for symlinking kernels/initrds on targets that use dtb.
-- Steve Langasek vor...@debian.org Fri, 30 May 2014 16:23:29 +0200
diff --git a/functions b/functions
index 9213145..d3009e8 100644
--- a/functions
+++ b/functions
@@ -631,14
Script handling at the time I wrote this.
On Fri, May 30, 2014 at 08:53:08PM +0100, Ian Campbell wrote:
On Fri, 2014-05-30 at 12:36 -0700, Vagrant Cascadian wrote:
On Fri, May 30, 2014 at 07:59:29PM +0100, Ian Campbell wrote:
On Fri, 2014-05-30 at 17:27 +0200, Steve Langasek wrote:
diff
... (no mention of an initramfs in the pastebin...)
--
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...@ubuntu.com
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 someone should probably test with it as a module, and file a bug
against the kernel package to have it enabled.
--
Steve Langasek
.
--
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...@ubuntu.com vor
://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 to set it on, and I can
think it's clear
that the support can be killed off now.
--
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 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 the offer, it makes it very interesting
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 % speed
improvement across the whole range of devices armhf runs on adds up to a big
deal.
--
Steve
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 to set it on, and I can move the world.
Ubuntu Developer
, and there are no syscalls
that take floating point arguments, let alone using floating point registers
to pass them.
--
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
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 Langasek Give me a lever
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 Developerhttp://www.debian.org/
slanga
-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 as it's not a distro... :)
--
Steve Langasek
.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 to set
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 their architecture.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move
needs to be maintained in a readily consumable fashion.
Given those constraints, I don't think that using a modified set of GNU
triplets is any better than creating new strings from scratch.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
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 mind here?
--
Steve Langasek
uclibc ABIs and how to specify these?
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.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com
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 at a consensus about how these things should be put together.
Which is what this thread is about. :)
Thanks,
--
Steve Langasek Give me
-config for
linking.
I don't argue that this makes --as-needed *correct* as a default, but I
think it's clear how using --as-needed may benefit a distribution in terms
of reducing churn when library dependencies change.
--
Steve Langasek Give me a lever long enough and a Free OS
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 to set it on, and I can move the world.
Ubuntu Developer
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...@ubuntu.com
On Mon, Jul 19, 2010 at 07:02:32PM +0100, Hector Oron wrote:
2010/7/18 Steve Langasek vor...@debian.org:
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 to map triplet-port
... if you want to run both armel and armhf under multiarch... which
package's libc gets to own ld.so? :P)
--
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
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 prevails. :)
--
Steve Langasek
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 Developerhttp://www.debian.org/
slanga
On Fri, Sep 25, 2009 at 06:06:35PM +0100, Martin Michlmayr wrote:
* Steve Langasek vor...@debian.org [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
the one
down_read(current-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 lever
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 PROTECTED] http://www.debian.org
than
having a version which does work on some(?)/most(?) hardware.
My biggest worry is that this is not a hardware issue at all but a kernel
issue, and we'll be bitten post-release when the kernels on the autobuilders
are changed.
--
Steve Langasek Give me a lever long enough
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 set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org
, 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, what can I do to help get that information?
--
Steve Langasek
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 Give me a lever long enough and a Free OS
Debian Developer
,
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 seems explicitly targetted for arm systems, but is deep in
the java chain listed above... :/
--
Steve Langasek Give
of a
sudden?
Anyways, a manual binNMU forcing the use of ecj-bootstrap 3.1.2-6 should
solve the issue.
A binNMU *of* ecj-bootstrap to get it updated to 3.2-1 would be a better
starting place.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
can be found at
http://buildd.debian.org/fetch.php?pkg=gst-plugins-base0.10arch=armver=0.10.9-1stamp=1153184849file=log.
Some of the errors suggest the problem may be linked to arm's unique FP
handling. Please consult the debian-arm list (cc:ed) for assistance.
--
Steve Langasek
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
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 two
months from now? :)
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
young
blocked by libpng hich is missing an arm build
Should actually be rebuilt on arm and sparc to lose this libpng dependency;
queued.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world
least
document this in the release notes if we need to.
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
-- this architecture-specific failure more likely points
to a kernel ABI issue specific to ARM.
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
] 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
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* of not supporting
the architecture. ;)
--
Steve Langasek
postmodern programmer
signature.asc
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
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
74 matches
Mail list logo
