> jenkins.d.n would be the place to put full-system cross-grading tests.
> piuparts would be the place to put per-package cross-grading tests.
FWIW, I just went through a cross-grade of a Lil'Debi chroot from armel
to armhf. I wouldn't recommend it to someone who's not used to command
line use of
Ian Jackson writes:
> I think I will probably do the i386->amd64 crossgrade on chiark some
> time during the supported life of stretch. I certainly don't expect
> it to be straightforward and I wouldn't dare trust it to a script.
> Just a data point.
Adding a similar data point for two of my p
Christoph Biedl writes ("Re: armel after Stretch (was: Summary of the ARM ports
BoF at DC16)"):
> Doing this by hand is of course neither fast nor simple. The migration
> script you requested could change that, however it's a delicate job,
> full of pitfalls, desaster if
[ limiting to devel- ]
Wouter Verhelst wrote...
> I think a proper procedure should involve a script that:
[ sane criteria ]
> We currently don't have anything remotely like the above, and I think we
> should.
Yes, but I doubt it would be used a lot. There's a wide-spread culture
of re-install
Lennart Sorensen wrote...
> I actually highly doubt there are that many armv7 boxes running armel.
> armhf was a nice performance improvement and worth the hassle to reinstall
> if you had such a box in the first place. I think most armel systems
> are probably armv5, often the marvell chips. No
On Sat, Dec 17, 2016 at 08:15:15PM +0800, Paul Wise wrote:
> On Sat, 2016-12-17 at 09:45 +0100, Wouter Verhelst wrote:
>
> > Yes, but that still says:
>
> Ack.
>
> > I think a proper procedure should involve a script that:
> >
> > - is packaged in Debian;
>
> Ack.
>
> > - checks whether the h
On Sun, Dec 18, 2016 at 11:22 PM, Roger Shimizu wrote:
> Is there any way to simplify?
Remove the obsolete armel binaries where they occur and then mark the
packages as NFU on armel:
https://wiki.debian.org/ftpmaster_Removals
https://wiki.debian.org/PackagesArchSpecific
--
bye,
pabs
https://w
On Sat, Dec 10, 2016 at 12:22 PM, Wookey wrote:
>
> We can do poor-mans partial arch by just being fairly agressive about
> disabling armel for packages that are broken or not suitable. Not very
> clever or efficient, but it is easy to do and requires no infra or
> tooling changes at all. So long
On Sat, 2016-12-17 at 09:45 +0100, Wouter Verhelst wrote:
> Yes, but that still says:
Ack.
> I think a proper procedure should involve a script that:
>
> - is packaged in Debian;
Ack.
> - checks whether the hardware it's running on has all the hardware
> requirements for the new architectur
On Sat, Dec 17, 2016 at 09:45:01AM +0100, Wouter Verhelst wrote:
> On Thu, Dec 15, 2016 at 11:19:34AM +0800, Paul Wise wrote:
> > On Thu, Dec 15, 2016 at 1:40 AM, Wouter Verhelst wrote:
> >
> > > One way in which the need to keep armel around would be reduced is if we
> > > could somehow upgrade f
On Thu, Dec 15, 2016 at 11:19:34AM +0800, Paul Wise wrote:
> On Thu, Dec 15, 2016 at 1:40 AM, Wouter Verhelst wrote:
>
> > One way in which the need to keep armel around would be reduced is if we
> > could somehow upgrade from armel machines to armhf ones, without
> > requiring a reinstall.
>
> T
Hello.
recent u-boot for kirkwood armel devices:
http://forum.doozan.com/read.php?3,12381
Regards
--
Nos vemos en los bares.
J. Carlos
On 2016-12-16, Roger Shimizu wrote:
> On Sat, Dec 10, 2016 at 11:31 PM, Christoph Biedl
> wrote:
>>> Is it possible to put a bootloader like u-boot in the flash partitions
>>> and have it load the Linux kernel and initrd from elsewhere?
There's no technical reason this wouldn't be possible, just
[CC Vagrant, u-boot pkg maintainer]
On Sat, Dec 10, 2016 at 11:31 PM, Christoph Biedl
wrote:
> Paul Wise wrote...
>>
>> Is it possible to put a bootloader like u-boot in the flash partitions
>> and have it load the Linux kernel and initrd from elsewhere?
>
> That how I've been running my Dockstar
On Thu, Dec 15, 2016 at 1:40 AM, Wouter Verhelst wrote:
> One way in which the need to keep armel around would be reduced is if we
> could somehow upgrade from armel machines to armhf ones, without
> requiring a reinstall.
There is a script for that here:
https://wiki.debian.org/CrossGrading
--
On Wed, Dec 14, 2016 at 06:40:22PM +0100, Wouter Verhelst wrote:
> On Wed, Dec 07, 2016 at 08:50:40PM +0900, Roger Shimizu wrote:
> [...asking for armel to be retained...]
>
> One way in which the need to keep armel around would be reduced is if we
> could somehow upgrade from armel machines to ar
On Wed, Dec 07, 2016 at 08:50:40PM +0900, Roger Shimizu wrote:
[...asking for armel to be retained...]
One way in which the need to keep armel around would be reduced is if we
could somehow upgrade from armel machines to armhf ones, without
requiring a reinstall.
After all, armel has been around
On 2016-12-13 23:42 +0100, Adam Borowski wrote:
> On Tue, Dec 13, 2016 at 09:21:48PM +0100, Christoph Biedl wrote:
> > W. Martin Borgert wrote...
> > > The forementioned hardware needs < 0.5 W, the manufacturer even
> > > claims 0.18 W. AFAIK, most newer ARM boards that are capable to
> > > run Deb
On Wed, Dec 07, 2016 at 03:53:31PM +, Steve McIntyre wrote:
> AFAIK there are potentially still similar problems with ARMv5 - lack
> of architcture-defined barrier primitives for C++11 atomics to
> work. (I'd love to be corrected on this if people know better!) This
> is one of the key points h
On Tue, Dec 13, 2016 at 09:21:48PM +0100, Christoph Biedl wrote:
> W. Martin Borgert wrote...
> > The forementioned hardware needs < 0.5 W, the manufacturer even
> > claims 0.18 W. AFAIK, most newer ARM boards that are capable to
> > run Debian need more energy or am I wrong?
>
> So let me play th
W. Martin Borgert wrote...
> The forementioned hardware needs < 0.5 W, the manufacturer even
> claims 0.18 W. AFAIK, most newer ARM boards that are capable to
> run Debian need more energy or am I wrong?
So let me play the devil's advocate another time: My Dockstar runs
24/7 and allegedly consume
Roger Shimizu wrote:
>On Thu, Dec 8, 2016 at 12:53 AM, Steve McIntyre wrote:
>>
>> There are kernel helpers available to provide some atomic support, but
>> they'll be very slow compared to real hardware support at this level.
>
>Are those kernel helper already reached Debian?
>Or there's still so
On Fri, Dec 09, 2016 at 06:42:19PM -1000, Julien Cristau wrote:
>On 12/09/2016 05:22 PM, Wookey wrote:
>> We can do poor-mans partial arch by just being fairly agressive about
>> disabling armel for packages that are broken or not suitable. Not very
>> clever or efficient, but it is easy to do and
2016-12-09 0:12 GMT+02:00 Christoph Biedl :
> Same here. My Dockstars (orion5x/kirkwood) still work like a charm and
> it gives a bad feeling having to trash them some day just because
> there's no support any more.
>
> On the other hand, they face another problem I guess is typical for
> that gene
On Sun, 11 Dec 2016 09:14:09 +0100, Marc Haber
wrote:
> And, while we're at it, how is "locale" pronounced? I have a native
> speaker in my filter bubble who claims that it's short for "local
> environment" and therefore pronounced "local e", but that sounds wrong
> for me. Is the example pronounc
On Thu, 8 Dec 2016 23:12:20 +0100, Christoph Biedl
wrote:
>Locale generation needs a lot of RAM. You can work around it by
>installing locales-all which however takes long time to install on
>slow flash drives. Or disable locales entirely. Err.
Or build a locale-local package that only contains t
On 2016-12-10 21:40, Adam Borowski wrote:
> Once you go down from 3GB memory that P4 in my cellar has to 128MB your
> armel box is limited to, the number of uses gets sharply limited. Even
> simple "apt update" takes ages.
The (multiple!) machines with 128 MB we run, have a dedicated
repository w
On Sat, Dec 10, 2016 at 05:54:29PM +0100, Christoph Biedl wrote:
> Certainly, with some limits though. At some point new hardware is that
> much more energy efficient the inital cost pays off over the intended
> time of usage. Want my old P4 server?
That P4 server can drive a bunch of disks and se
On 2016-12-10 17:54, Christoph Biedl wrote:
> Maximum RAM is 128 Mbytes. Wouldn't buy this to run Debian on it.
Depends on the use case. My employer is using it successfully
since years. Of course: No X, no database, no big data, but some
hungry Pythons and a web interface :~)
> At some point new
W. Martin Borgert wrote...
> Quoting Ben Hutchings :
> >Also, dedicated tiny flash partitions for the kernel and initrd. I
> >wouldn't be surprised to be find that by the time we want to release
> >buster we can't build a useful kernel that fits into the 2 MB partition
> >that most of these devic
Paul Wise wrote...
> On Fri, Dec 9, 2016 at 8:53 AM, Ben Hutchings wrote:
>
> > Also, dedicated tiny flash partitions for the kernel and initrd. I
> > wouldn't be surprised to be find that by the time we want to release
> > buster we can't build a useful kernel that fits into the 2 MB partition
On 12/09/2016 05:22 PM, Wookey wrote:
> We can do poor-mans partial arch by just being fairly agressive about
> disabling armel for packages that are broken or not suitable. Not very
> clever or efficient, but it is easy to do and requires no infra or
> tooling changes at all. So long as someone is
On Sat, 2016-12-10 at 09:54 +0800, Paul Wise wrote:
> On Fri, Dec 9, 2016 at 8:53 AM, Ben Hutchings wrote:
>
> > Also, dedicated tiny flash partitions for the kernel and initrd. I
> > wouldn't be surprised to be find that by the time we want to release
> > buster we can't build a useful kernel th
On 2016-12-07 15:53 +, Steve McIntyre wrote:
> On Wed, Dec 07, 2016 at 08:50:40PM +0900, Roger Shimizu wrote:
> >I'm ARM porter on armel/marvell (orion5x/kirkwood).
> >Stretch will be frozen and released soon, which makes me bit depressed,
> >because it means armel will be dropped out of unst
On Fri, Dec 9, 2016 at 8:53 AM, Ben Hutchings wrote:
> Also, dedicated tiny flash partitions for the kernel and initrd. I
> wouldn't be surprised to be find that by the time we want to release
> buster we can't build a useful kernel that fits into the 2 MB partition
> that most of these devices s
On 12/09/2016 01:53 AM, Ben Hutchings wrote:
> On Thu, 2016-12-08 at 23:12 +0100, Christoph Biedl wrote:
>> Roger Shimizu wrote...
>>
>>> I'm ARM porter on armel/marvell (orion5x/kirkwood).
>>> Stretch will be frozen and released soon, which makes me bit depressed,
>>> because it means armel will
On Fri, 2016-12-09 at 22:14 +0900, Roger Shimizu wrote:
> On Fri, 09 Dec 2016 00:53:17 +
> > Ben Hutchings wrote:
>
> > Also, dedicated tiny flash partitions for the kernel and initrd. I
> > wouldn't be surprised to be find that by the time we want to release
> > buster we can't build a usef
Quoting Ben Hutchings :
Also, dedicated tiny flash partitions for the kernel and initrd. I
wouldn't be surprised to be find that by the time we want to release
buster we can't build a useful kernel that fits into the 2 MB partition
that most of these devices seem to have.
Non-HF devices can be
On Fri, 09 Dec 2016 00:53:17 +
Ben Hutchings wrote:
> Also, dedicated tiny flash partitions for the kernel and initrd. I
> wouldn't be surprised to be find that by the time we want to release
> buster we can't build a useful kernel that fits into the 2 MB partition
> that most of these devic
On Thu, 2016-12-08 at 23:12 +0100, Christoph Biedl wrote:
> Roger Shimizu wrote...
>
> > I'm ARM porter on armel/marvell (orion5x/kirkwood).
> > Stretch will be frozen and released soon, which makes me bit depressed,
> > because it means armel will be dropped out of unstable/testing as the
> > c
Roger Shimizu wrote...
> I'm ARM porter on armel/marvell (orion5x/kirkwood).
> Stretch will be frozen and released soon, which makes me bit depressed,
> because it means armel will be dropped out of unstable/testing as the
> conclusion of Cape Town BoF.
Same here. My Dockstars (orion5x/kirkwood
On Thu, 2016-12-08 at 20:19 +0900, Roger Shimizu wrote:
> Dear Steve,
>
> Thanks for your comments!
> Very informative!
>
> > On Thu, Dec 8, 2016 at 12:53 AM, Steve McIntyre wrote:
> >
> > There are kernel helpers available to provide some atomic support, but
> > they'll be very slow compared t
Dear Steve,
Thanks for your comments!
Very informative!
On Thu, Dec 8, 2016 at 12:53 AM, Steve McIntyre wrote:
>
> There are kernel helpers available to provide some atomic support, but
> they'll be very slow compared to real hardware support at this level.
Are those kernel helper already reach
On Wed, Dec 07, 2016 at 05:05:58PM +0100, Emilio Pozuelo Monfort wrote:
>On 07/12/16 16:53, Steve McIntyre wrote:
>> * It will need somebody happy to dive into the lower levels of the
>>various toolchains to verify support for atomics and make things
>>work where it's not already, by addin
On 07/12/16 16:53, Steve McIntyre wrote:
> * It will need somebody happy to dive into the lower levels of the
>various toolchains to verify support for atomics and make things
>work where it's not already, by adding support for the kernel
>helpers.
There has been some recent work on t
On Wed, Dec 07, 2016 at 08:50:40PM +0900, Roger Shimizu wrote:
>[ intentionally keep d-d CCed ]
>
>On Fri, 22 Jul 2016 02:36:05 +0100
>Steve McIntyre wrote:
>
>> [ Please note the cross-post and Reply-To ]
>>
>> Hi folks,
>>
>> As promised, here's a quick summary of what was discussed at the ARM
[ intentionally keep d-d CCed ]
On Fri, 22 Jul 2016 02:36:05 +0100
Steve McIntyre wrote:
> [ Please note the cross-post and Reply-To ]
>
> Hi folks,
>
> As promised, here's a quick summary of what was discussed at the ARM
> ports BoF session in Cape Town.
Thanks for the summary!
I'm ARM port
47 matches
Mail list logo
